Tag Archives: validity

Digital Certificates Explained

Posted on by
2

Digital Certificates Explained KB ID 0001846

Problem

From setting up PKI environments, to migrating them, and a myriad of errors and problems in between, we have a lot of content on PNL referring to digital certificates and PKI. I’ve dealt with these technologies a lot over the past 20+ years and I’m always surprised how frightened of digital certificates people are. So in the space of a few minutes I’ll try and give you a basic understanding of what PKI is, how that relates to Digital certificates, then finish off with a few certificate ‘Golden rules‘.

Solution : Digital Certificates Explained

You will see I use the terms PKI environment, and Certificate Services  and interchange those two things a lot, Certificate Services is the name of the Microsoft ‘Role” that provides Certificate Services. If you simply want to setup certificate services, then use the following link.

Microsoft PKI Planning and Deploying Certificate Services

Before you understand certificates, you need to have a basic understanding of Public Keys, and Private Keys, how this key pair is used, and what Asymmetric Cryptography is (bear with me the maths might be mind boggling, but the concept is simple).

Public Key

The public key is shared openly and is used to encrypt messages or data. It is associated with a user (or entity) and can be freely distributed to anyone. Its primary function is to ensure confidentiality by allowing others to encrypt messages that only the owner of the corresponding private key can decrypt.

Private Key

The private key is kept secret and is known only to the owner. It is used for decrypting messages or data that have been encrypted with the corresponding public key. The private key is crucial for ensuring the authenticity and integrity of the data because only the person with the private key can decrypt and access the information.

Digital Certificates Explained: How These Keys are Used for Encryption

Encryption

1. Sender obtains the recipient’s public key and uses the recipient’s public key to encrypt the message.
2. Encrypted message is sent to the recipient.

Decryption

3. The recipient, (who possesses the corresponding private key), can then decrypt the message.

The strength of the security lies in the complexity of the key pair. Asymmetric cryptography is based on mathematical principles, making it computationally infeasible for someone to calculate the private key even if they have the corresponding public key. This makes it a secure method for tasks such as secure communication, digital signatures, and online transactions.

Digital Certificates Explained: Use of Keys and Certificates

Public Key Infrastructure (PKI) is a framework that manages digital keys and certificates. it requires the following:

Key Pair Generation: The process begins with the generation of a key pair (the public and private keys) for a user or entity. As shown above the public key is shared openly, and the private key is kept secret.

Certificate Authority (CA):A Certificate Authority is a trusted third party (public) or you own (private) system for authenticating digital certificates. in a PKI system.
The user’s public key is combined with other information (such as identity details and time stamps,) and then signed by the CA to create a digital certificate.

Digital Certificates: A digital certificate is a data structure that binds a public key to an individual, device, or service. It includes the public key, and information about the entity, the digital signature of the CA, and other metadata. So the digital certificate serves as a way for others to verify the authenticity of the associated public key and ultimately the identity of the entity.

Certificate Lifecycle: Certificates have a defined lifecycle, including issuance, and expiration. Note: They can also be revoked before expiration for example if compromised, or if the associated private key is lost.

Usage in Secure Communication

When parties want to communicate securely, they exchange their digital certificates. So just like the example above, the sender encrypts data with the recipient’s public key, which they get from the certificate that the receiver has published publicly, ensuring only the recipient, with the corresponding private key, can decrypt it.
Note: Digital signatures, created using the sender’s private key, can also be attached to messages to ensure authenticity and integrity. The recipient can verify the signature using the sender’s public key.

Digital Certificates Explained: Golden Rules Of Certificates

You must trust the CA that issued (authorised) the Certificate.

Every certificate has a CA that issued/approved it you NEED TO TRUST that CA, there are several trusted Certification Authorities that are built into your computer, and these are updated regularly with normal updates. this is why if you self-sign a certificate or build your own CA – then you may need to manually get people to trust your CA before they will be trusted. Also Certificate Authorities are hierarchical (they can have parent CAs) these form a CHAIN, and you need to be able to see that chain and trust ALL the CAs in that chain, (all the way back to the Root CA).

 

Above on my (current) site certificate you can see it was issued by a CA called RapidSSL, and that CA was authorised by a Root CA called Digicert Global Root G2. This means my certificate was signed by an intermediate CA (sometimes called and Sub CA).

The Certificate needs to be In Date

Certificates a have a date they were issued and a date when they will expire, If you are not at a point in time between these two dates, then you will not trust the certificate. (Note: this can happen if the internal clock/date on YOUR machine is incorrect).

 

 

Note: A Certificate that is in date can also be revoked. This is done by the CA, which publishes a list of certificates that have been revoked, (that your computer can check.)

The Common Name (CN) and/or Subject Alternative Name (SAN)  needs to be correct.

In times gone by, the certificate CN had to be correct, but more modern browsers will require BOTH Common Name and Subject Alternative Name to be correct. these are fields in the certificate that hold the name of the entity for example mine is www.petenetlive.com (that is the Common Name) This is the address (or FQDN) that is typed into the browser window to get to the site that presents this certificate.

 

Note: That means if you are putting a certificate on ‘something‘ be that a website, or a device, the NAME needs to be both correct, and resolvable by the person (or entity) that you want to trust it, e.g. if the common name was www.petes-site.com and you needed to type in https://www.petenetlive.com to get there, it would not be trusted (even if both names resolved to the correct IP address!)

You need to trust the ‘Algorithm‘ that signed the certificate.

This is a more recent development, I mentioned above that there’s some very complicated maths going on, as time moves on the mathematics needs to get more complicated, as computers get more powerful to maintain security. So older methods of signing have been depreciated, if a certificate is using technology that’s been depreciated it will also not be trusted.

 

Here’s an example of what happens when the signature algorithm is not trusted.

ERR_CERT_WEAK_SIGNATURE_ALGORITHM

Here’s an example of what happens if the CN or SAN values are wrong.

ERR_CERT_COMMON_NAME_INVALID

Related Articles, References, Credits, or External Links

NA

Edge View Certificate Information

Posted on by
Reply

Edge View Certificate Information KB ID 0001815

Problem

Not sure why, but I spend a large amount of time working on certificate problems, being asked questions about certificates, or fixing certificate problems. For certs that are web presented, back in the days of IE I could simply do this.

For those sniggering at my IE use – I typically work on client’s sites where I can’t go round installing browsers that are not terrible! Now that was all fine, now we (finally have got rid of IE (mostly)). How do I do the same with Edge?

I was losing my temper trying to fix my test Exchange server certificates today. Because I could not find the same information with Microsoft Edge. As it transpires the information is there, Microsoft have just done their best to hide it!

Edge View Certificate Information: Solution

You need to click the ‘padlock’ > Connection is Secure > Then click the small Icon at the top > the certificate details are then displayed on two tabs, the information is not as well formatted as it used to be, but it’s all there.

 

 

Related Articles, References, Credits, or External Links

NA

Microsoft PKI Planning and Deploying Certificate Services

Posted on by
26

KB ID 0001309

Problem

“I don’t know what it is about Certificates, I just don’t like them, I don’t understand them, and I don’t like working with them”

I hear this a lot, In fact I heard it this week, and as I’m usually the ‘go-to-guy’ for certificates and PKI, it winds me up! IT pros take the time to learn concepts like DNS, DHCP, Kerberos etc. But mention Certificate Services and heads disappear below monitors and silence decends.

OR WORSE: Someone adds the role, clicks Next > Next > Next > Job done! Lets have tea and medals!

So in typical PNL fashion lets simplify everything, get everyone on the same page. And most importantly, lay out how to do it so I don’t have to do it for you!

Solution

To design PKI well, you need to decide if you want a two or three tier PKI environment. 

What can’t I just have one CA Server? (Hmm your the Next > Next > Next > Job Done Person Eh?) Well you can! But if that one server breaks, (or get compromised.) Then you are in trouble. Plan you deployment properly and save yourself a headache.

Two Tier Or Three Tier PKI? That’s your call, The main advantage of three tier PKI is, if one of your issuing servers, is compromised, you don’t need to bring the offline Root CA back online to re-issue its certificate. I have a client who have an issuing server in their DMZ so this was a good fit for them. For most domains Two Tier is the best option.

So I can only have one issuing Server? No, I just put one on the diagram for simplicity, you can have 1, or 100, or 1000, it’s up to you.

Do I need CRL (Certificate Revocation List) and/or OCSP (Online Certificate Status Protocol) On a Separate Server? Strictly speaking No, but it’s considered good practice, and if you need to advertise a CRL externally, it is more secure. 

PKI Terminology Differences

You will notice I’ve mentioned a Root CA, an Intermediate CA, and an Issuing CA. This is to better explain the architecture and define a difference between an Intermediate CA, and an Issuing CA. Microsoft does not care,.Both of those servers are SubCA servers in Microsoft speak. 

Deploying an Offline Root CA

Whichever architecture you choose this will be your fist step. The offline Root CA is a non domain joined machine, its sole job is to issue SubCA certificates to your intermediate CAs (three tier PKI), or issuing CAs (two tier PKI). When you have finished you power off the Offline Root CA and keep it off.

Note: In my example I want my Root CA Cert to last 20 years

Before You Install Anything: Create a CAPolicy.inf file you can edit it with notepad. You may want to change the validity period, you certainly will need to change the legal notice URL (more on this later) to your own domain FQDN (Note: If you need people outside your organisation, (either at a partner, or just someone the public internet) to see that, ensure that URL is addressable.

Sample Offline Root CA CAPolicy.inf

[box]

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://pki.cabench.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0

[/box]

Save the CAPolicy.inf file to C:\Windows, Make sure it’s not called Capolicy.inf.txt, (or it wont work).

Launch Server Manager > Manage > Add Roles and Features.

Role Based >  Next > Select the local server > Next  > Select ‘Active Directory Certificate Services’ > Add Features  > Next.

No other features are required > Next > Next > Certification Authority > Next.

Next > Next > Close.

Configure Active Directory Certificate Services.

Accept the default (local administrator) > Next > Certification Authority > Next.

Stanalone CA > Next > Root CA > Next.

Create a new private key > Next > Make sure the hash algorithm is SHA 256 (NOT SHA1) > Next.

Give the CA a sensible name > Next > Set the validity period (as mentioned above I’m going for 20 years) > Next.

All the default can now be accepted > Next > Next > Close.

Launch the Certification Authority Management console and make sure we have a green tick.

Now we need to ‘Stamp’ Certificates issued by this CA Server with some domain information, but we have no connection to the domain, so we need to do it manually. Open an administrative command window and execute the following commands;

Note: I want my SubCA certificate to be valid for 15 years, if you want longer/shorter then adjust the figures below

[box]

Certutil –setreg CA\DSConfigDN “CN=Configuration,DC=cabench,DC=com”

Certutil –setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.cabench.com/pki/%1_%3%4.crt”

Certutil –setreg CA\CRLPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.cabench.com/pki/%3%8%9.crl”

Certutil –setreg CA\CRLPeriodUnits 52 

Certutil –setreg CA\CRLPeriod “Weeks” 

Certutil –setreg CA\CRLOverlapPeriodUnits 12 

Certutil –setreg CA\CRLOverlapPeriod “Hours” 

Certutil –setreg CA\ValidityPeriodUnits 15 

Certutil –setreg CA\ValidityPeriod “Years” 

Certutil –setreg CA\AuditFilter 127

net stop certsvc

net start certsvc

Certutil –crl

[/box]

Now my Offline Root server is not connected to a network, (because that’s best practice,) and as it’s a virtual machine the only way to get files from it is to use a virtual floppy drive, Im going to copy both my Root CA Certificate and CRL file to my floppy drive.

[box]Copy C:\Windows\System32\Certsrv\CertEnroll\*.* A:\[/box]

Now TAKE THESE FILES TO A DOMAIN JOINED MACHINE, and execute the following commands.

[box]

cd a:\
certutil -dspublish -f 01-Root-CA_ROOT-CA.crt RootCA
certutil –addstore –f root 01-Root-CA_ROOT-CA.crt
certutil –addstore –f root ROOT-CA.crl
certutil -dspublish  ROOT-CA.crl

[/box]

Note: These command publish the CA Certificate, (and its CRL) into Active Directory. You can see where, if you open the path shown in the example in ADSIEdit.msc (CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain})

See Microsoft PKI Planning and Deploying Certificate Services Part 2

Related Articles, References, Credits, or External Links

NA