I have visited other pages on that site as Vadims has reposted many blogs that are now hard to find due to Microsoft archiving a lot of the content. Vadims has done a lot of great work here.
I have come across many questions in regard to whether when deploying a PKI if a two tier PKI hierarchy and whether an offline root should be used.
The answer is yes an offline Root should be used in pretty much all environments. So, why? Some might ask, I have a super small environment, do I really need to this. The answer is, yes. So, again why?
First what is the reason for having an offline Root which pretty much guarantees that you would have to then setup a two or three tier hierarchy?
Root CA
The Root CAs main role is to be the trust anchor for the PKI hierarchy. In other words, the self-signed certificate that the Root CA generates is distributed to all devices that will need to trust the PKI. So, when you have a Root CA and Issuing CAs are subordinate to that CA, you only have one certificate to distribute. So, no matter how many issuing CAs you decide to deploy, you only have one Root certificate to distribute. Some applications may require you to install the subordinate CAs, but many applications can fetch the subordinate CAs from the AIA repository.
Two Tier Hierarchy?
So, let’s say you have a small environment, and you are only planning to install one Issuing CA. Do you still need an offline root and two-tier hierarchy? Yes. The reason you still want to have this, is because it allows you to later expand your PKI if necessary. You can later add additional issuing CAs that terminate in the same trusted root. And while you may only need one CA at this time, it is impossible to anticipate the future needs of your organization, so by deploying a two tier PKI you enable your PKI to be scalable. If you do not install a two tier hierarchy you are limited. Because if you later decide to expand your PKI, you either need to rebuild with an offline Root or manage multiple Issuing CAs that are also Root CAs. So, to avoid these future limitations you still would want to deploy a two tier PKI, or in some edge case scenarios a three tier PKI.
Offline Root
What is an offline root? An offline Root is a Root CA that is disconnected from the network for it’s entire “lifetime”. The OS should be installed without network connectivity, and the machine should never be connected to a network, not even for a minute.
What are the inconveniences of having an offline Root?
The main problem is that you periodically must update the CRL, then copy the CRL to the CRL Distribution Points (CDP) repositories. And if this CRL expires, it can cause outages in your environment.
So, do you need to make your Root CA and offline CA?
Yes. As mentioned earlier the Root CA is the trust anchor of the PKI. Also, you want to put as much security around CAs as possible since if they are compromised certificates that are trusted in your environment can be issued. And if a malicious actor compromises your CA, they can impersonate identities in your environment. So, the security guidance is to have CAs offline if they infrequently issue certificates. Issuing CAs are online because they issue certificates very frequently. Root CAs and Policy CAs are kept offline because they issue certificates very infrequently.
To explain this further, let’s us a fictional scenario. Let’s say you have an Offline Root CA, and you have an Issuing CA that only issues Code Signing certificates for your organization. And let’s say due to the sensitivity of these types of certificates you want to provide maximum security for the Code Signing CA. And your development group typically only requests Code Signing certificates 5 time a year. In this scenario you would keep the CA offline and only bring it online 5 times a year. And if possible, like the Root CA you would set it up as a standalone CA and keep it disconnected from the network (offline). Sure, this makes administration a bit harder since you have to sneaker-net the requests to the CA and the certificates off the CA. But it dramatically increases the security of the CA, so it is worth the trade off.
So, to answer the question “Why have an offline root?”
Because the CA infrequently issues certificates and CRLs
Because compromise of the CA can result in a compromise, or assist in the compromise of your environment (Possibly including Active Directory)
If it is not connected to the network, it cannot be attacked from the network
It is best practice and if your PKI gets audited you will be flagged for not having it offline
If you later have to convert the CA to an offline CA, you will have to potentially revoke previously issued certificates and renew the Root CA certificate, if not have to redeploy the Root CA altogether
Why should I not deploy a single tier PKI?
Having the Root CA online violates best practice, due to the reasons above
The PKI is not scalable (We want to future proof deployments, so we can avoid having to redeploy the PKI in the future)
If your PKI is audited, you will be flagged during the audit, since your Root CA is online
There are several tools you can use to troubleshoot certificate validation. The best tool is certutil -verify -urlfetch. That tool is the best because it checks all certificates in the chain and gives us a lot of validation information. You can find information on how to use that tool, at the end of the following blog: Certificate Validation – xdot509.blog.
However, there is a GUI tool that can be used: certutil -url. The disadvantage to this tool is that it just checks one certificate at a time and mostly provides information on the accessibility of CDP, AIA, and OCSP. So, if you just want to check that your repositories are accessible this is a good way to perform that check. It is also easier to understand the output form this tool, which can make it easier for you to communicate your issue to your colleagues when you are troubleshooting.
To run the command, you first need a certificate file. So, you can export the certificate and save it to a file location. If it is a website you are having trouble with you can export the cert from the lock icon in the browser.
The syntax of the command is: certutil -url <Certificate File Name>, where <Certificate File Name> is the certificate file you previously exported. This will launch the GUI.
The tool is pretty self-explanatory, but the graphic below provides some additional information.
If you click Certs (from AIA) and click Retrieve it will verify that it can retrieve the certificates from the AIA repository and that they are the correct certificates.
If you select CRLs (from CDP) and click Retrieve it will verify that it can retrieve the certificates from the AIA repository and that they are the correct certificates.
And finally, you can select OCSP (from AIA) and click Retrieve it will verify that OCSP is working
This blog posting covers certificates. The purpose of this post is for those who would like to better understand certificates, their structure, and their contents. This blog post also covers basic management of certificates.
1.2 What is a certificate?
A certificate is a digital document that binds an identity to a public key. The identity contained in a certificate can be associated with any number of things including computers, users, and services such as a web site. Certificates also contain additional information that makes the certificate more useful in many respects.
Public Key cryptography makes use of two related keys. There is a public key and a private key. Any data that is encrypted with the public key can be decrypted the private key. Also, any data that encrypted with the private key can be decrypted with the public key. The public key is distributed via certificates and the private key is protected on a computer or on a cryptographic device such as a smart card.
Certificates also have a period of time for which they are valid. In other words, a certificate is valid for a certain period of time. This built in expiration mechanism helps increase the security of certificates. This is due to the fact that if a certificate is compromised and that compromise is not detected it will eventually expire and become invalid.
There is some basic information you can get from a certificate by viewing it in the Windows UI. However, for most troubleshooting you will want to look at the certificate fields which will be discussed in the next section.
In the General Tab you can look at a description of the purposes of the certificate. You can also get the identity of the subject and the issuer. You can view the validity period of the certificate. If there is a private key associated with the certificate available in the certificate store you will see that as well.
In the Details Tab you will see all of the fields listed in the certificate as well as some additional information supplied by the Operating System. We will discuss these fields in the next section. You can also use the Copy to File… button to export a certificate.
The Certification Path Tab shows the chain of the certificate, starting at the current certificate and going up as far as the Root CA. There is also a Certificate status section that can be used for identifying issues with the certificate in terms of trust or validation.
To better understand certificates including how they are used and validated we need to understand the various fields that are contained in a certificate.
Certificates contain two types of fields Version 1 Fields and Extensions.
Version 1 fields are those that were specified in the original specification for X.509 certificates defined in RFC 1422.
1.7.1.1 Version
This field indicates the X.509 version that is being used. The current version of the X.509 standard is Version 3.
1.7.1.2 Serial Number
Serial Number is a unique identifier for each certificate. The Serial Number should be unique at least on a per CA basis. In other words, a Certification Authority should not issue more than one certificate with the same Serial Number.
1.7.1.3 Signature Algorithm
This field contains the name of the Public Key Algorithm and Hashing Algorithm that were used to sign the certificate.
1.7.1.4 Issuer
This field indicates the name of the CA that issued the certificate
1.7.1.5 Valid From (Validity Period)
This field indicates at what date and time the certificate becomes valid.
1.7.1.6 Valid To (Validity Period)
This field indicates at what date and time the certificate expires
1.7.1.7 Subject
This field contains the identity that is bound to the public key of the certificate. The identity is bound to that public key duet to the fact that the certificate contains both the public key as well as the identity are contained within a certificate that is signed by a trusted certification authority.
1.7.1.8 Public key
This field contains the public key that is bound to the certificate.
After the publication of RFC 1422 the idea of extensions in certificates were introduced in a later RFC. Extensions are optional fields that can be included in a certificate. However, generally the extensions included in RFC 5280 should be understood by PKI enabled applications.
1.7.2.1 Subject Key Identifier
This field contains a hash of the public key in the certificate, this information is one way to identify the certificate.
1.7.2.2 Authority Key Identifier
This field contains a hash of the public key that is contained in the CA certificate, this is one way to identify the certificate of the CA that issued the current certificate.
1.7.2.3 CRL Distribution Points
This field indicates where Certificate Revocation Lists can be downloaded from to determine if the certificate has been revoked.
1.7.2.4 Authority Information Access
This field indicates where the certificate of the CA that issued the certificate can be downloaded. This field will also indicate where the OSCP service can be accessed, if one is available in the environment.
1.7.2.5 Key Usage
This field indicates what purposes the keys in the certificate can be used for and these purposes include Digital Signature, Key Encryption, Key Agreement, Certificate Signing, CRL Signing, Key Agreement Enciphering, Key Agreement Deciphering.
1.7.2.6 Certificate Template Information
This is a Microsoft specific extension which means it is note one included in the RFC 5280, as such it would only be expected to be understood by Microsoft applications. This field contains the name and OID of the Certificate Template.
1.7.2.7 Certificate Template Name
This is a Microsoft specific extension which means it is note one included in the RFC 5280, as such it would only be expected to be understood by Microsoft applications. This field contains the name of the Certificate Template.
1.7.2.8 Enhanced Key Usage
This extension specifies for what purposes the public key may be used.
1.7.2.9 Application Policies
This extension specifies for what applications the certificate can be used.
1.7.2.10 Subject Alternative Name
The Subject Alternative Name or SAN is an optional field that contains the identity or identities that are bound to the certificate. The SAN extension is typically used when the certificate will contain more than one identity. To elaborate further identity information can be stored in either the subject field, the Subject Alternative Name extension or both. Some services such as SSL with ignore the subject field if the Subject Alternative Name extension is populated.
1.7.2.11 Basic Constraints
Typically, this extension is only included in CA certificate and identifies the certificate as a CA certificate.
In Windows certificates can be stored in a number of places, so let’s discuss the various locations where certificates are stored and the benefits of storing certificates in these locations.
Certification Authorities by default store a copy of every issued certificate in its database. Storing certificates in the CA Database enables the following capabilities:
Retrieval- Having a copy of each certificate provides a central repository from where certificates can be retrieved by enrollees or a certificate manager.
Recovery- Certificates can be recovered for a user or computer since a copy of the certificate is stored in the CA Database. Additionally, if Key Archival is enabled the private key can be recovered for encryption certificates.
Forensics and Analysis: The database can be searched to determine what certificates have been issued and provide useful information such as when a certificate expires.
Revocation: If a certificate has been compromised or is no longer trusted that certificate can easily be located in the CA database and revoked.
Certificates can be stored on the userCertificate attribute of a user or computer that enrolls for a certificate. Publishing certificates to a computer or user object is typically not necessary for most applications. However, some applications such as EFS or Email Encryption can query Active Directory for the certificate of the user that the document or email for which it is being encrypted.
As previously mentioned the certificate is published to the userCertificate during enrollment. The certificate is published by the Certification Authority. The Cert Publishers security group is the group that has permission to write to the userCertificate attribute. In order for the CA to be able to publish a certificate to the userCertificate attribute it must be a member of the Cert Publishers group in the corresponding Active Directory domain.
Additionally, the certificate template must be configured to Publish certificate in Active Directory as seen in the screenshot below:
1.9.2.1 Viewing the userCertificate Attribute
There are several ways to view certificates that are stored in the userCertificate attribute.
1.9.2.1.1 Certmgr.msc
If a user opens Certmgr.msc they can view what certificates are stored on their user object by navigating to the Active Directory User Object node.
1.9.2.1.2 Active Directory Users and Computers
To view the userCertificate attribute in Active Directory Users and Computers navigate to the user or computer whose userCertificate attribute you wish to view. Open the properties for the user or computer account and navigate to the Published Certificates tab. If the Published Certificates tab is not available, you need to enable Advanced Features in the Active Directory Users and Computers View menu.
1.9.2.1.3 ADSIEDIT
To view the userCertificate attribute connect to the Domain Partition (Default Naming Context). Go to properties on the corresponding object and navigate to the userCertificate attribute.
For certificates that are stored on the local machine for the computer or user these certificates are stored on the local file system or registry. The only exception to this is if you are storing certificates and/or keys on a cryptographic device such as a TPM or Smart Card.
The following tables illustrate where certificates are stored on the local computer.
The following table shows where Computer certificates are stored on the computer.
1.9.3.1 Protection of Private Keys that are stored locally
Private keys are protected by the Data Protection Application Programming Interface (DPAPI). DPAPI protects the private keys with encryption and that encryption is accessed with a key that is a derivation of the user or computer’s password.
Certificates can also be stored on a cryptographic device called a Smart Card. Smart cards are typically credit card size and require a smart card reader. However, there are also USB smart cards that have an integrated smart card reader. Regardless, these devices have an integrated circuit and cryptographic functions are performed on that hardware. Certificates and private keys are stored on the smart card. To use the keys on that smart card a user must have knowledge of the PIN associated with that smart card and must enter the PIN when using the smart card. The key advantage is that the private keys are protected by hardware. A secondary advantage is the smart card provides a mechanism to roam the user’s certificates and keys. This is due to the fact that the certificates and keys can be used on any system where the user inserts their smart card.
Starting in Windows 8.0 the capability to store certificates on the Trusted Platform Module chip was introduced. A Virtual Smart Card is created on the TPM and the certificate is stored on the Virtual Smart Card which is protected by the TPM. The Virtual Smart Card offers some of the advantages of physical smart card in the sense that the private keys are protected by hardware and cryptographic functions that require use of the private key occur on the TPM. However, since the TPM is physically part of the computer certificates do not roam with the user as they do in the case of physical smart cards. However, in some cases that is a practical advantage since physical smart cards can be lost or forgotten by the user.
A Hardware Security Module (HSM) is a dedicated cryptographic security device for protecting keys. In PKI we use an HSM to protect the private keys that are linked to a certificate and that are part of a public/private key pair. HSMs are commonly used to protect the Private Keys of Private Keys are isolated to prevent tampering or exportation of the Private Keys. Cryptographic functions that require use of the private key occur in the HSM. HSMs typically use K of N security to prevent a single individual from having control of the HSM. K of N security means that a certain number of credentials have to presented in order to make changes to the HSM. For example, if 5 credentials are provisioned for administrative actions on HSM, you can configure the HSM so that at least 3 of those 5 credentials must be presented to the HSM for administrative actions to be performed. There are several types of HSMs currently used. There are USB HSMs that are typically used for an Offline CA or for Code Signing. There are PCI Express HSMs that can be used with a Physical CA. However, the most commonly type used of HSM that I have seen in use are Network HSMs. Network HSMs are connected to via Ethernet.
There are a number of tools that are used for certificate administration. The most common tool that you may end up using for certificate administration is the Certificates MMC. The Certificates MMC itself can be targeted at the certificate store of a user, a computer, or a service account. However, you will most commonly use the Certificates MMC for administration of user or computer certificates, and hence we will focus on administration of user and computer certificates.
Certmgr.msc is the certificates MMC for managing user certificates. Using this MMC you can perform the following actions for the user:
View Certificates
Import Certificates
Export Certificates
Enroll for Certificates
View Requests
Generate Certificate Request
Process Approved Certificate Requests
Below is a screenshot of the Certmgr.msc:
The table below describes the purpose of each container in Certmgr.msc.
Folder Name
Contents
Personal
Certificates associated with private keys to which you have access. These are the certificates that have been issued to you, or to the computer or service for which you are managing certificates.
Trusted Root Certification Authorities
Implicitly trusted certification authorities. Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your organization and Microsoft.
Enterprise Trust
A container for certificate trust lists. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
Intermediate Certification Authorities
Certificates issued to subordinate certification authorities.
Active Directory User Object
Certificates associated with your user object and published in Active Directory.
Trusted Publishers
Certificates from certification authorities that are trusted by Software Restriction policies.
Untrusted Certificates
An untrusted certificate is a certificate that a certification authority has revoked, or a certificate that for other reasons has been placed in the Untrusted Certificates folder on your computer.
Third-Party Root Certification Authorities
Trusted root certificates from certification authorities other than Microsoft and your organization.
Trusted People
Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.
Client Authentication Issuers
A list of issuers whose certificates are trusted for TLS/SSL Client Authentication.
Certificate Enrollment Requests
Pending or rejected certificate requests.
Smart Card Trusted Roots
On smart card insertion, the Certificate Propagation service propagates any root certificates on the card to the Smart Card Trusted Roots certificate stores on the local computer. This process establishes a trust relationship with the organization.
Certlm.msc is the Certificate MMC for managing certificates for the local computer. Prior to Windows 8.1 the shortcut (certlm.msc) was not available for launching the Certificate MMC targeted to the local computer. So, for pre-Win8 or pre-Windows Server 2012 machines the following steps can be used to launch the Certificates MMC targeted for the local computer.
Steps for Opening Certificates MMC Targeted for Local Computer
Step 1: Click the Start key and then the R key
Step 2: Type mmc.exe and click OK
Step 3: In the new console select the File menu and from the File menu select Add/Remove Snap-in…
Step 4: Select Certificates and then click the Add button
Step 5: Select Computer account and then click Next
Step 6: Select Local computer: (the computer this console is running on), and the click Finish
Step 7: Click OK
The Certificates MMC targeted for the Local Computer will now be Open
1.10.2.1 Certlm.msc Uses
The following tasks for the local computer can be performed using certlm.msc:
View Certificates
Import Certificates
Export Certificates
Enroll for Certificates
Generate Certificate Request
Below is a screenshot of the Certmgr.msc:
The table below describes the purpose of each container in Certlm.msc.
Folder Name
Contents
Personal
Certificates associated with private keys to which you have access. These are the certificates that have been issued to you, or to the computer or service for which you are managing certificates.
Trusted Root Certification Authorities
Implicitly trusted certification authorities. Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your organization and Microsoft.
Enterprise Trust
A container for certificate trust lists. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
Intermediate Certification Authorities
Certificates issued to subordinate certification authorities.
Trusted Publishers
Certificates from certification authorities that are trusted by Software Restriction policies.
Untrusted Certificates
An untrusted certificate is a certificate that a certification authority has revoked, or a certificate that for other reasons has been placed in the Untrusted Certificates folder on your computer.
Third-Party Root Certification Authorities
Trusted root certificates from certification authorities other than Microsoft and your organization.
Trusted People
Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.
Client Authentication Issuers
A list of issuers whose certificates are trusted for TLS/SSL Client Authentication.
Remote Desktop
Certificates that are used to provide SSL security for RDP connections.
Smart Card Trusted Roots
On smart card insertion, the Certificate Propagation service propagates any root certificates on the card to the Smart Card Trusted Roots certificate stores on the local computer. This process establishes a trust relationship with the organization.
Web Hosting
Highly scalable certificate store for SSL certificates that can support thousands of certificates to support increased secure site density.
The following video provides additional information on certificates:
One important concept to understand when troubleshooting certificates. This blog covers the basics of understanding certificate validation. Then towards the end, I cover troubleshooting steps.
1.2 Identity Validation
Certificates bind an identity to a public key. And one of the reasons that we use certificates is to ensure that we are accessing the resource that we intend to access. Therefore, we expect the identity in the certificate to match the identity we are trying to access. For example, if you enter the following URL in your web browser: https://www.microsoft.com, you would expect that the identity www.microsoft.com would be included in the certificate. There are two possible fields in the certificate where this identity information can be located: Subject and Subject Alternative Name. The Subject is a Version 1 field that will typically only contain one identity. The Subject Alternative Name field is an extension and is typically used when there is more than one identity in the certificate. For some applications such as SSL, the subject will be ignored if the SAN is populated. Below is an example of an error a user might receive if there is a mismatch between the identity that they are trying to contact and the identity in the certificate.
In order to determine if a certificate is trusted, you need to build a chain to the root certificate. Once the chain is built to the root certificate you can determine whether or not the root certificate is trusted. To validate the chain, you must have possession all of the certificates in the chain and then you can build the chain from the end-entity certificate all the way up to the root certificate, which is a self-signed certificate where the chain terminates. I will discuss more about Chain Validation later on in this document.
Certificates also have a period of time for which they are valid. In other words, a certificate is valid for a certain period of time. This built in expiration mechanism helps increase the security of certificates. This is due to the fact that if a certificate is compromised and that compromise is not detected it will eventually expire and become invalid.
The Valid From field is when the certificate begins its validity period and the Valid To field indicates when a certificate ends its validity period. In order for a certificate to be valid from a time perspective, the current date should fall in between the Valid From and Valid To dates specified in the certificate.
When a Windows client checks the revocation status of a certificate it checks revocation for that certificate and every certificate in the chain excluding the Root CA certificate.
The client will first check to see if it has any time valid OCSP Responses or CRLs cached locally.
If an OSCP URI has been deployed via Group Policy the client will send and OCSP response to the OCSP Responder. The OCSP responder then should send a response back to the client informing the client whether or not the certificate has been revoked.
If an OCSP URI is included in the AIA extension of the certificate the client will send and OCSP response to the OCSP Responder. The OCSP responder then should send a response back to the client informing the client whether or not the certificate has been revoked.
If there is no OCSP URI Specified the client will download the Base CRL. If the Base CRL has a Freshest CRL extension the client will then download the Delta CRL. The client will then parse the CRL(s) to determine if the certificate has been revoked.
As mentioned earlier a certificate needs to be chained to a root certificate in order to determine if the certificate chains to a trusted root. There is information included in certificates to assist in this chain building process. The most common type of information I see used to help the system identify the chain or the Subject Key Identifier (SKI) field and the Authority Key Identifier (AKI) field. The Authority Key Identifier is a hash of the certificate issuers public key. The Subject Key Identifier is a hash of the public key in the current certificate. The Operating System can chain a certificate by matching the Authority Key Identifier field in a certificate to the Subject Key Identifier in the issuer’s certificate. Matching the Authority Key Identifier field in the certificate to the Subject Key Identifier of the issuer is commonly called a key match.
Keep in mind not only do the fields have to match but the signature needs to verify as well. A certificate is digitally signed by the issuer. This means the certificate data was passed through a hashing algorithm and then the resulting hash is encrypted with the private key of the issuer. The signature can be verified by hashing the same certificate data, decrypting the digital signature with the public key of the issuer, and comparing the hashes. If the resulting hashes match and the digital signature can be decrypted with the issuer’s public key then the signature is verified.
Remember that the verifier of the certificate must have all certificates in the chain. The verifier will have access to the certificate it is verifying usually during a handshake during a protocol setup. Intermediate certificates may also be distributed the same way. However, if the intermediate certificates are not distributed during the protocol handshake they can be downloaded from the AIA repository. There is an extension named Authority Information Access that is commonly included with certificates. The AIA extension usually has a url which indicates from where the issuer’s certificate can be retrieved from. Windows supports two protocols for retrieval of CA certificates via the AIA Repository: LDAP and HTTP. Also, keep in mind that you have multiple AIA locations specified in the AIA extension of the certificate. Those AIA locations are processed in the order in which they are present the AIA extension.
Below is an example of the AIA extension in a certificate:
1.6.1.1 LDAP Repository
When we talk about using an LDAP repository to host CA certificates we typically mean using the LDAP functionality of Active Directory. Although, other ldap providers can be used for hosting CA certificates it is less common and does not provide the same level of integration as Active Directory.
There are some significant advantages and disadvantages to using LDAP as an AIA repository:
1.6.1.1.1 Advantages
High Availability: When using Active Directory as the LDAP provider, there is built-in fault tolerance. This is due to the fact that the AIA location is stored in the Configuration container that is replicated to all Doman Controllers in the forest.
Site Awareness: Active Directory has built-in site awareness. Clients use DCLocator to find the nearest DC, so clients will be able to pull certificates from a local Domain Controller.
1.6.1.1.2 Disadvantages
3rd Party Support: PKI can be leveraged by 3rd party Operating Systems and applications. Many of these are not integrated into Active Directory and hence cannot access the Active Directory LDAP provider.
Insecure Networks: Providing access to Active Directory LDAP over insecure networks such as a DMZ or Public Network would be a security nightmare so it would not be a good practice to use LDAP if clients on an insecure network need to retrieve the CA Certificates from AIA.
1.6.1.2 HTTP Repository
Using an HTTP or Web Repository is a more common practice. This is especially true for Public or 3rd Party CAs. If using an HTTP repository, it is important that the repository can be located by a DNS name and that the DNS name is not tied to a specific machine. In other words, you would likely use a CNAME or an A record that is not the computer name of the Web Server.
1.6.1.2.1 Advantages
Insecure Networks: Just about every organization is familiar on how to make the http protocol accessible in DMZ’s or over the Internet.
3rd Party Support: The virtual directory where the CA certificates are made accessible is normally configured to allow anyone to read and hence download the CA certificates.
1.6.1.2.2 Disadvantages
High Availability: A web server by itself is not highly available. Additional work and resources must be brought to bear to make a website highly available including having multiple web servers typically behind a load balancer.
Site Awareness: If you wish to make the HTTP AIA repository available locally to every site it requires additional web servers and a load balancer that will re-direct clients to the closest web server.
1.6.1.3 AIA Design Considerations
When you are in the process of building a PKI you have to decide where the AIA locations are going to be located and how the names used to access those locations are going to be formed. A common practice for 3rd Party Certification Authorities is just to use a single http URL inside of the AIA extension. Then that web location is made available from a highly available provider such as a Content Delivery Network (CDN). For your own internal PKI you have a number of possible ways to make the HTTP AIA location highly available. You could use for instance Azure CDN to provide a highly available solution. Alternatively, you could stand up several web servers behind a load balancer to provide this functionality. Regardless, when you design the name for the AIA location you will want to choose a name that is not tied to a specific machine name. Even if you do decide to go against best practices and host the HTTP AIA location on the CA itself, you would still want to use some sort of alias instead of the machine name. This configuration would allow you flexibility in the future if you ever decide to move that location to another machine. This is due to the fact that aside from reconfiguring where the certificate was published you would simply just need to update where that DNS alias is pointed instead of having to re-configure the AIA location which would require renewing the CA certificate to update the extension in that certificate. Additionally, if you plan on using the PKI to secure internet facing resources you would want to ensure that the DNS name used for the AIA location is not just resolvable internally, but also externally. Aside from the HTTP location some organizations decide to leverage LDAP as a secondary AIA location that would be available if the HTTP location is inaccessible.
The Root CA’s primary function is to be the trust anchor for the PKI. When a system trusts a Root CA, then that trust extends to subordinate CAs that chain to that same root and the certificates that they issue.
In order for a Root CA to be trusted on a Windows system the Root CA certificate must be present in the Trusted Root Certification Authorities store. Keep in mind there Trusted Certification Authorities container in both the Computer certificate store and the User certificate store. Trusted Root CA Certificates present in the Computer store are inherited by the user. There are a number of ways that a Root CA certificate can be populated in that store.
Microsoft has a program where 3rd Party CAs can submit their certificate to be installed in the Trusted Root Certification Authorities store. These are the Root CA certificates that ship with Windows. The advantage to this approach is that a user or organization does not need to go out download and install the Trusted Roots for popular 3rd Party CAs.
Root CA Certificates can be deployed via Group Policy. This is a common way organizations deploy Root CA Certificates for the PKI of a trusted organization. Root CA certificates may also be deployed this way during a Merger or Acquisition.
Autoenrollment performs a variety of functions. One of those functions is to download Enterprise Certificates from Active Directory. Enterprise Certificates includes the Root CA certificates that are published to the Certification Authorities container as well as downloading Subordinate CA certificates from the Authority Information Access container in Active Directory. All of these containers are located in the Configuration Partition of Active Directory.
Unless otherwise prevented by Group Policy users can add Root CA certificates in the Trusted Root Certification Authority container in the user store. A user that has administrator privileges can also add Root CA certificates to the Trusted Root Certification Authorities container in the Computer certificate store.
In order to determine whether or not a certificate should be trusted, the certificate chain must be built. Starting with the certificate that is being validated, the validator locates the next certificate in the chain. If that certificate is an intermediate CA that cert can be retrieved locally from the Intermediate Certification Authorities container, passed to the validator during the protocol handshake for whatever protocol is using the certificate, or retrieved from the AIA extension in the certificate. This process continues until it reaches a self-signed certificate or in other words a Root CA certificate. If that Root CA certificate exists in the Trusted Root Certification Authority store that the certificate being validated is considered trusted.
Certificates do have a limited time for which they are valid. This built-in expiration mechanism enhances the security of certificates. However, there are times where you may no longer trust a certificate before it expires. There are several possible reasons why you may no longer trust a certificate. Some of those reasons include: the certificate was compromised, the computer was compromised, or the user left the company. When you no longer trust a certificate you can revoke. Once the certificate is revoked, applications that perform revocation checking will no longer trust the certificate. More specifically the CA Manager and Certificate Manager can revoke the certificate. When an administrator revokes a certificate they must specify a reason for the revocation. These reason include: Unspecified, Key Compromise, CA Compromise, Change of Affiliation, Superseded, Cease of Operation, and Certificate Hold. If the Certificate Hold reason is selected, the certificate can later be unrevoked.
The following steps can be taken to revoke a certificate
Step 1: To revoke a certificate the Certificate Manager open the Certification Authority MMC (certsrv.msc)
Step 2: Click on Issued Certificates
Step 3: Right-click on the certificate that needs to be revoked
Step 4: From the context menu click All Tasks and the Revoke Certificate
Step 5: Select a reason for the revocation
Step 6: Click OK
The Revoked Certificate will show up under Revoked Certificates. The certificate will not be known to be revoked until the CRL is published to the CDP and subsequently downloaded and parsed by clients checking revocation.
A Certificate Revocation List contains a list of certificates that have been revoked. Specifically, CRLs contain the Serial Number of each certificate that has been revoked, along with the reason for revocation, and the date and time that the certificate was revoked. There are two types of CRLs: Base CRLs and Delta CRLs. Base CRLs contain a list of all non-expired certificates that have been revoked. Delta CRLs contain a list of non-expired certificates that have been revoked since the last Base CRL was published. The lists from the latest Base CRL and Delta CRL can be combined to get a list of all non-expired certificates that have been revoked. Delta CRLs were implemented so that clients would not have repeatedly download a base CRL which would be larger in size. So, instead of publishing a Base CRL more frequently, delta CRL can be published instead. Delta CRLs are optional you can just use a Base CRL if that better fits the requirements for your organization.
In this section I will discuss the various fields that are included in a CRL.
1.9.3.1 Version
This is the Version of the CRL Profile that is being used. The current version of the CRL Profiles is Version2.
1.9.3.2 Issuer
The Issuer field indicates which CA issued the CRL.
1.9.3.3 Effective date
This is the date and time at which a CRL becomes effective.
1.9.3.4 Next update
Next update indicates the date and time at which the CRL will be expired.
1.9.3.5 Signature Algorithm
The Signature Algorithm field indicates what Asymmetric Cryptographic Algorithm and Hashing Algorithm were used to sign the CRL.
1.9.3.6 Signature Hash Algorithm
The Signature Hash Algorithm field indicates the Hashing Algorithm used when signing the CRL
1.9.3.7 Authority Key Identifier
The Authority Key Identifier is another way of identifying the issuer of the CRL. Specifically, the Authority Key Identifier field contains a hash of the issuer’s public key
1.9.3.8 CA Version
The CA Version Field list the version number for the CA Certificate that was used to sign the CRL.
1.9.3.9 CRL Number
The CRL Number indicates the version of the CRL. The CRL Number increments each time a new CRL is published.
1.9.3.10 Next CRL Publish
The Next CRL Publish field indicates the date and time at which the next CRL will be published.
1.9.3.11 Published CRL Location
Published CRL Location is the location at which the CRL will be published in Active Directory. This is typically
1.9.3.12 Freshest CRL
If a CA publishes Delta CRLs then the Freshest CRL extension will show the location(s) where Delta CRLs can be retrieved.
1.9.3.13 Revocation List
The Revocation List will list every non-expired certificate that has been revoked. This list will include the Serial Number and revocation date. Depending on the reason code selected it may also list the reason for the revocation.
A Delta CRL contains a list of all non-expired certificates that have been revoked after the publication of the Base CRL. To determine the location of the Delta CRL the Freshest CRL extension of the Base CRL must be read or known. To determine revocation, the current Base CRL and latest Delta CRL must be available.
1.9.4.1 Delta CRL Indicator
A Delta CRL has the same extension and formatting as a base CRL. A Delta CRL also has a field called Delta CRL Indicator. This field indicates which base CRL the client must have to have complete knowledge of revocations.
The CRL Distribution Points extension is an extension in a certificate that indicates where the CRL can be retrieved from for the purposes of checking revocation. That location where the CRLs can be retrieved is often referred to as a CDP repository. Some of the same concepts that apply to the Authority Information Access extension apply here, but I have listed them below for completeness.
1.9.5.1 LDAP Repository
When we talk about using an LDAP repository to host CA certificates we typically mean using the LDAP functionality of Active Directory. Although, other ldap providers can be used for hosting CA certificates it is less common and does not provide the same level of integration as Active Directory.
There are some significant advantages and disadvantages to using LDAP as an AIA repository:
1.9.5.1.1 Advantages
High Availability: When using Active Directory as the LDAP provider, there is built-in fault tolerance. This is due to the fact that the AIA location is stored in the Configuration container that is replicated to all Doman Controllers in the forest.
Site Awareness: Active Directory has built-in site awareness. Clients use DCLocator to find the nearest DC, so clients will be able to pull certificates from a local Domain Controller.
1.9.5.1.2 Disadvantages
3rd Party Support: PKI can be leveraged by 3rd party Operating Systems and applications. Many of these are not integrated into Active Directory and hence cannot access the Active Directory LDAP provider.
Insecure Networks: Providing access to Active Directory LDAP over insecure networks such as a DMZ or Public Network would be a security nightmare so it would not be a good practice to use LDAP if clients on an insecure network need to retrieve the CA Certificates from AIA.
1.9.5.2 HTTP Repository
Using an HTTP or Web Repository is a more common practice. This is especially true for Public or 3rd Party CAs. If using an HTTP repository, it is important that the repository can be located by a DNS name and that the DNS name is not tied to a specific machine. In other words, you would likely use a CNAME or an A record that is not the computer name of the Web Server.
1.9.5.2.1 Advantages
Insecure Networks: Just about every organization is familiar on how to make the http protocol accessible in DMZ’s or over the Internet.
3rd Party Support: The virtual directory where the CA certificates are made accessible is normally configured to allow anyone to read and hence download the CA certificates.
1.9.5.2.2 Disadvantages
High Availability: A web server by itself is not highly available. Additional work and resources must be brought to bear to make a website highly available including having multiple web servers typically behind a load balancer.
Site Awareness: If you wish to make the HTTP AIA repository available locally to every site it requires additional web servers and a load balancer that will re-direct clients to the closest web server.
1.9.5.3 CDP Design Considerations
When you are in the process of building a PKI you have to decide where the CDP locations are going to be located and how the names used to access those locations are going to be formed. A common practice for 3rd Party Certification Authorities is just to use a single http URL inside of the CDP extension. Then that web location is made available from a highly available provider such as a Content Delivery Network (CDN). For your own internal PKI you have a number of possible ways to make the HTTP CDP location highly available. You could use for instance Azure CDN to provide a highly available solution. Alternatively, you could stand up several web servers behind a load balancer to provide this functionality. Regardless, when you design the name for the CDP location you will want to choose a name that is not tied to a specific machine name. Even if you do decide to go against best practices and host the CDP AIA location on the CA itself, you would still want to use some sort of alias instead of the machine name. This configuration would allow you flexibility in the future if you ever decide to move that location to another machine. This is due to the fact that aside from reconfiguring where the CRL was published you would simply just need to update where that DNS alias is pointed instead of having to re-configure the CDP location which would require renewing the CA certificate to update the extension in that certificate. Additionally, if you plan on using the PKI to secure internet facing resources you would want to ensure that the DNS name used for the CDP location is not just resolvable internally, but also externally. Aside from the HTTP location some organizations decide to leverage LDAP as a secondary CDP location that would be available if the HTTP location is inaccessible.
1.9.5.4 CRL Publishing
So, how do we maximize the amount of time we have for recovery, and at the same time increase the “freshness” of the CRL? We can do this with the use of Overlap Periods.
So, let’s say we want to implement this solution that maximizes recovery time and increases CRL freshness. The first consideration is Delta CRLs. Since Delta CRLs in my view are not necessary in most instances, we will first get rid of Delta CRLs. So, now that gives us just Base CRLs to work with. Let us take our Base CRL and make it valid for a period of 3 days. So, at first you would think great, now I have 3 days to recover the CA if the CA fails since the CRL is valid for 3 days. Well this is not true. If the validity period of the CRL and the publishing interval coincide, then you could have as little time as 1 second depending on when the CA failed. The illustration below exemplifies this scenario. The problem is without changing the default configuration the Next Update and Next Publish fields will be very close together, providing very little time for recovery.
1.9.5.5 Introducing CRL Overlap Period
As mentioned there is some additional configuration that can be performed that can optimize your CRL publishing intervals so that you have adequate time to perform Emergency CRL Signing or to recover your CA. What will need to be configured is the CRL Overlap Period. In order to configure the CRL Overlap Period both the CRLOverlapUnits and CRLOverlapPeriod registry settings need to be configured. So, in my previous example my CRL had a validity period of 3 days. What I can do now is add a CRL Overlap Period of 3 days. With this configuration, my CRL will be valid for a period of 6 Days. However, at 3 days a new CRL will be published as well. This is illustrated in the graphic below:
In the example illustrated in the graphic above, CRL 1 will be valid for a period of 6 days. CRL 2 will be published at Day 3. So, if my CA fails between Day 1 and Day 3, I would still have 3 Days (Day 3 through Day 6) to perform Emergency CRL signing or to recover my CA in event of failure. If my CA fails between Day 3 and Day 6, there is a new CRL (CRL 2) that is valid through Day 9. So, in short if my CA fails between Day 3 and Day 6, I still have at least 3 days to perform Emergency CRL Signing or to recovery my CA, before revocation checking starts to fail. And the reason that I have the 3 days is the CRL Overlap Period extended out my CRL for 3 days and staggered the Next Publish and Next Update times by 3 days.
You can use the errors visible in the Windows UI to troubleshoot Certificate Validation. Below are a sample of some errors you may encounter in the Windows UI.
This CA Root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store.
This error simply indicates that the Root CA Certificate is not trusted.
Windows does not have enough information to verify this certificate.
This error indicates that the client verify the certificate does not have access to all of the certificates in the chain.
The issuer of this certificate could not be found.
This error indicates that the client verify the certificate does not have access to all of the certificates in the chain.
This certificate has expired or is not yet valid.
This error typically indicates that the certificate is expired.
Certutil -verify -urlfetch is perhaps the best tool to check the validation of a certificate. You will want to run this tool on a machine which appears to have validation issues. For example, if a client is visiting a website that is secured with TLS you would want to copy the certificate to the client and run this tool from the client. This command does all of the validation checks including checking of the AIA, CDP, and OCSP locations are accessible and contain valid configuration. The normal syntax for running the command is: certutil -verify -urlfetch [File Name of Certificate] > [Name of Output Text File].
Below are screenshots or a sample output of certutil – verify -urlfetch to help you better understand how to read this file.
Here are some of the information or error messages you can receive at the end of the output from the command:
Leaf certificate revocation check passed
Indicates that the certificate passed the verification check.
A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495 CERT_E_EXPIRED)
Typically means the certificate is expired.
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
This means that the verifier was unable download a CRL.
The certificate is revoked. 0x80092010 (-2146885616 CRYPT_E_REVOKED)
Indicates that the certificate has been revoked.
Conclusion
That covers certificate validation. For additional information see the following video.
There may be times when you need to replace the service account for the NDES service. One scenario is if your organizations gets compromised. After a compromise it is common to change the passwords for service accounts and in some cases to replace the service accounts entirely. Of course, there may be other reasons to replace service accounts as well. Today we will review the steps needed to replace the NDES service account and walkthrough the process.
Steps to Replace NDES service account
Stop the SCEP Application Pool
Create new service account
Remove any custom SPNs from the existing service account
Add any custom SPNs to the new service account
Add the account to the IIS_IUSRS group on the NDES server(s)
Add the account to the certificate template that is being provisioned
Give the new service account read permissions to the private key of the service certificates
Replace the service account in the SCEP Application Pool
Start the SCEP Application Pool
Remove previous service account from the IIS_IUSRS group
Remove previous service account from private key permissions
Remove previous service account from certificate template(s)
Service Account Replacement Walkthrough
Stopping the Application Pool
Step 1: On the NDES Server, in Server Manager select Tools, then Internet Information Services (IIS) Manager
Step 2: Navigate to and select Application Pools
Step 3: Right-click on the SCEP Application Pool and then select Stop from the context menu
Creating the Service Account
Step 1: On your Adminstration Workstation open Active Directory Users and Computers
Step 2: Right-click on the OU that contains your service accounts
Step 3: From the context menu select New then User
Step 4: Fill out the Full name and User logon name the click Next
Step 5: Enter and confirm the password and select Password never expires if appropriate, then click Next
Step 6: Click Finish
Managing the SPNs (if applicable)
Step 1: Open an elevated command prompt on your Administration Workstation (as a Domain or Enterprise Admin)
Step 2: Run the following command: setspn -l <NDES Service Account Name>
Step 3: Not any custom SPNs (in my example it is http/ndes.fourthcoffee.com)
Step 4: To remove the SPN run the following command: setspn -D <SPN> <NDES Service Account Name>
Step 5: Add the SPN to the new service account by running the following command: setspn -S <SPN> <New NDES Service Account Name>
Adding the Service Account to the IIS_IUSRS group
Step 1: In Server Manager select Tools then Computer Management
Step 2: Navigate to Local Users and Groups, then Groups
Step 3: Open the IIS_IUSRS group
Step 4: Click Add…
Step 5: Enter the new service account and click OK
Step 6: Click OK
Managing Service Certificates Private Keys
Step 1: As a user that is local administrator on the NDES server open certlm.msc
Step 2: Navigate to Personal and then Certificates
Step 3: Locate the CEP Encryption certificate
Step 4: Right-click on the certificate and click All Tasks then Manage Private Keys…
Step 5: Click Add…
Step 6: Enter the service account and click OK
Step 7: Provision the new service account with just Read permissions
Step 8: Click OK
Step 9: Locate the Exhange Enrollment (Offline Request) certificate
Step 10: Right-click on the certificate and click All Tasks then Manage Private Keys…
Step 11: Click Add…
Step 12: Enter the service account and click OK
Step 13: Provision the new service account with just Read permissions
Step 14: Click OK
Give the New Service Account Enroll Permissions on the Certificate Template
Determine the certificate template(s) you are distributing with NDES
Step 1: On the CA logon as an Enterprise Admin
Step 2: Open the Certification Authority MMC
Step 3: Right-click on Certificate Templates and then select Manage from the context menu
Step 4: Navigate to the certificate template you are distributing with NDES
Step 5: Right-click on the certificate template and select Properties from the context menu
Step 6: On the certificate template click Add…
Step 7: Enter the new service account name and click OK
Step 8: Give the account Enroll permissions
Changing the Service Accounts in the SCEP Application Pool
Step 1: Open Internet Information Services (IIS) Manager on the NDES server as a member of the local administrators group
Step 2: Navigate to Application Pools
Step 3: Right-click on the SCEP application pool and select Advanced Settings…
Step 4: In Advanced Settings click on the … after the current service account (Identity)
Step 5: Click Set…
Step 6: Enter the service account in domain\user format and then enter and confirm the account password
Step 7: Click OK
Step 8: Click OK
Step 9: Click OK
Step 10: Return to the SCEP application pool
Step 11: Right-click on the SCEP application pool and select Start from the context menu
De-provisioning steps
The following steps need to be completed to deprovision the previous service account. However, these steps will not be covered by this walkthrough as those steps should be obvious after completing the above walkthrough.
Remove previous service account from the IIS_IUSRS group
Remove previous service account from private key permissions
Remove previous service account from certificate template(s)
I am writing this blog and others to explain how things work and some ways deployment and operational tasks can be handled. In other words, these postings are for demonstration purposes only. Since I am not familiar with your organization or environment I do not know if these steps are applicable to your environment or are even safe to perform in your environment. It is recommended that you contact Microsoft Support prior to making changes in your environment to ensure that these steps are applicable to your environment, and are safe to perform in your environment. By writing this blog I am in no way recommending that you perform these steps in your own environment. If you choose to follow the steps outlined in this or other blog postings on this site, you are assuming the risk for your actions.
Background
Sometimes if you are new to an environment or exploting PKI for the first time you may realize that you have Certification Authorities that are populated in Active Directory. Sometimes some of those CAs may no longer exist in the environment or you had some problems removing the CA from Active Directory. In those cases you can manually remove the PKI objects from Active Directory. This posting will cover how you can remove the CA and PKI objects from Active Directory
It is extremely important to note that you should not do this unless you are 100% certain that you are no longer going to use the Certification Authority or any certificates that have been issued from that Certification Authority.
The PKI objects exist in the Configuration partition of Active Directory. Hence, these objects are replicated to every Domain Controller in the forest. This means that it will require that the user that will be removing the PKI objects from Active Directory must be a member of the Enterprise Admins group. Also, keep in mind that since this is an Active Directory change so it will need to replicate to every DC in the forest which depending on your replication convergence time may take a while.
Pre-requisites
Access to a machine that has the Active Directory Certificate Services (ADCS) Remote Server Administration Tools (RSAT)
The machine must be a member of the Active Directory forest that hosts the CA
The user removing the PKI objects must be a member of the Enterprise Admins group
You have backed up Active Directory using a System State backup or other approved backup method
Removing the Deprecated CA and related PKI objects from Active Directory
Step 1: Logon to a machine with an account that is a member of the Enterprise Admins group
Step 2: Launch Enterprise PKI (PKIView.msc)
Step 3: Identify the CA you want to remove from Active Directory
Step 3: Right-click on Enterprise PKI and from the context menu select Manage AD Containers…
Step 4: On the NTAuthCertificates tab, select the certificate associated with the deprecated CA and click the Remove button
Step 5: When prompted to confirm the removal, click Yes
Step 6: Select the AIA Container tab
Step 7: Select the certificate associated with the deprecated CA and click the Remove button
Step 8: When prompted to confirm the removal click Yes
Step 9: If you are prompted that this is the last certificate in the object, click Yes to confirm the removal
Step 10: Navigate to the CDP Container tab
Step 11: If present select the Delta CRL associated with the deprecated CA and click the Remove button
Step 12: When prompted to confirm the deletion click Yes
Step 13: Select the Base CRL associated with the deprecated CA and click the Remove button
Step 14: When prompted to confirm the removal of the CRL click Yes
Step 15: If prompted that this is the last CRL in the object click Yes to confirm the removal
Step 16: If prompted that this is the last CDP object in the container click Yes to confirm the removal
Step 17: Navigate to the KRA Container tab
Step 18: If there are any certificates associated with the deprecated CA remove them
Step 19: Navigate to the Certification Authorities Container (If the CA is not a Root CA it may be absent from this container)
Step 20: Select the certificate associated with the deprecated CA and click Remove
Step 21: When prompted to confirm the deletion click Yes
Step 22: If prompted that this is the last certificate in the object, click Yes to confirm the deletion
Step 23: Navigate to the Enrollment Services Container (the CA may be absent from this container if ADCS was gracefully removed from the machine)
Step 24: Select the certificate associated with the deprecated CA and click Remove
Step 25: When prompted to confirm the deletion click Yes
Step 26: If prompted that this is the last certificate in the object, click Yes to confirm the deletion
Step 27: Click OK to close the window
Step 28: Right-click on Enterprise PKI and select Refresh from the context menu
Step 29: Verify that the deprecated CA is no longer displayed in Enterprise PKI (may have to wait until AD replication converges).
Below is a video of this same topic that I posted a few days before posting this blog entry.
Thank You for taking time out of your day to visit my blog!
I wanted to draw some attention to an NDES test tool that I have been using for a while. My thanks to the author (Hasain Alshakarti) of the toolbox and steps as it is one of the few ways that I am aware of to test NDES without access to actual hardware or an MDM solution. I am going to cover the steps to use the tool. I understand that the instructions on the authors website are pretty straight forward and pretty easy to follow. However, I think the screenshots may give you all an idea of what to expect when using the tool.
Once you have downloaded an extract the tool and perform the following steps:
Step 1: Access the mscep_admin site on your web server as a Device Admin. In my example this is http://fcndes01.fourthcoffee.com/certsrv/mscep_admin. Note: My certsrv directory is not protected with TLS. As a best practice it should be protected with TLS.
Step 2: Copy the enrollment challenge password for later use. In my example the password is BA86D09D04DAC557
Step 3: Open a command prompt and navigate to the directory where the tools were extracted
Step 4: Run openssl.exe req -config scep.cnf -new -key priv.key -out test.csr, to generate the reques
Step 5: Enter the Common Name (subject) for the certificate and click Enter
Step 6: Paste or manually enter the enrollment challenge password, then click Enter. In my example it is: BA86D09D04DAC557
Step 7: To retrieve the CA certificate (which is part of the NDES enrollment process), run the following command: sscep.exe getca -u http://<your NDES server DNS Name or IP address here>/certsrv/mscep/ -c ca.crt
The output you receive will look something like this:
Step 8: Run the following command to enroll for the certificate: sscep.exe enroll -uhttp://<your NDES server DNS Name or IP address here>/certsrv/mscep/> -k priv.key -r test.csr -l test.crt -c ca.crt-0 -e ca.crt-1
Step 9: Verify the pkistatus is Success
You can also open test.crt to verify the result:
In addition you can view the request in the IIS logs of the NDES server:
Thanks to Hasain Alshakarti for putting the toolbox and process to test NDES enrollment.
The following steps are the steps to reset the NDES service account password. This is pretty simple and straight forward.
Step 1: As a Domain Administrator or a user that has been delegated the ability to reset passwords open up Active Directory Users and Computers (dsa.msc)
Step 2: Locate the service account
Step 3: Right-click on the account and select Reset Password…
Step 4: Enter and confirm a password and click OK
Step 5: Click OK to acknowledge the prompt
Step 6: On the NDES server open Server Manager
Step 7: From the Tools menu select Internet Information (IIS) Manager
Step 8: Navigate to Application Pools
Step 9: Right-click on the SCEP application pool and select Stop
Step 10: Right-click on the SCEP application pool and select Advanced Settings…
Step 11: Click the 3 dots … after the service account under Identity
Step 12: In the Application Pool Identity window click the Set… button
Step 13: Enter the service account name in domain\user format
Step 14: Enter and confirm the password
Step 15: Click OK
Step 16: Click OK
Step 17: On Advanced Settings click OK
Step 18: Right-click on the SCEP application pool and select Start
That’s it. I’m going to continue writing NDES articles until I exhaust the topics that come to mind. At some point I will move on to configuration and known issues with the Web Enrollment Proxy.
This blog posting is just a list of PKI best practices and common practices. If you are implementing your own PKI or simply assessing your own PKI you can use this list to determine if your design or implementation is inline with industry best practices. This is by no means an exhaustive list, just common and best practices that I am aware of.
Offline CAs such as Root and Policy CAs are only brought on the network for administrative tasks such a Certificate Renewal or CRL Renewal. These Certification Authorities typically have CRLs with a long validity period such as 6 months or 1 year. Due to this configuration Offline CAs should be configured to not publish Delta CRLs and to not populate the Freshest CRL extension in Base CRLs.
FTP is not supported as an AIA or CDP repository in Windows and SMB locations are no longer supported in Windows for AIA and CDP locations. Therefore, FTP and SMB locations should not be used for AIA and CDP.
To help ensure the security of CA certificates they should have a key length of 2048 or larger. This larger key space is currently considered secure. There have been security issues found with keys that are 1024 or smaller. Additionally, certificates that are issued by the PKI should have a key length of 2048 or large if RSA is used.
Since offline CAs are not regularly connected to a network they should not be members of an Active Directory domain. Another reason for not making these CAs a member of the domain as it can potentially increase the number of users that have administrator privileges on the machine that host the Certification Authority.
Windows does not perform a revocation check on the Root CA. Therefore, a CDP location defined in the Root CA certificate is unnecessary. Also, a CRL published for the Root CA would need to be published by itself. So, whether a Root CA is trusted or not should be determined by including the Root CA certificate the Trusted Root Certification Authority store, and if it is not trusted it should be removed from this store. In other words, trust of the Root CA certificate should not depend on its serial number being included in a CRL. Also, there is no need to have an AIA location defined in a Root Certificate. Because if you were to include one it would define a location where the Root CA certificate is located and can be retrieved. However, if you are viewing the AIA extension on a Root CA certificate you already have possession of the certificate.
For ease of configuration AIA locations can use the default variables, by default this looks like %1_%3%4. This translates to <ServerDNSName>_<CAName><CertificateName>. The %4 variable is the most important variable and the one that should be kept even if you decide to use a different name for the certificate. This variable configures the CA to increment the number of a certificate as new certificates are issued. So, for example if the first CA certificate is named MYCACERT.crt, after renewal the new certificate name would be MYCACERT(1).crt. And if the certificate is renewed a second time the new filename would be MYCACERT(2).crt.
There is a similar situation for the CRLs. The default syntax is %3%8%9. This translates to the
<DeltaCRLAllowed> will configure the CA to include a character/symbol to represent a delta
CRL. By default, the + sign is used. So, if the base CRL is MYCA.crl the delta CRL would be MYCA+.crl. The <CRLNameSuffix> is the most import variable. This appends the incrementing number at the end of the CRL name each time the CA certificate is renewed with a new key. This only happens when the certificate is renewed with a new key because if the key does not change the CRL can be signed with a key that is used by the current and previous certificate. However, if a new key is generated the CA will create a separate CRL for each key that is associated with a valid CA certificate. So, again the <CRLNameSuffix> allows for the incrementing number at the end. An example would be that the first CRL is named MYCA.crl, after a key renewal the new CRL will be named MYCA(1).crl and so on.
The main point here is that the %4 variable is important for CA Certificate paths and the %8 variable is critical for CRL paths. Without these variables the CA would simply overwrite the existing file.
CRLs for Offline CAs should not have a validity period that exceeds one year. Typical configuration for a CRL for an offline CA is 6 months or 1 year. The reason for the longer validity periods is due to the fact that in order to publish a new CRL the Offline CA needs to be brought online. Having longer validity period reduces how often the Offline CA needs to be accessed.
Certification Authorities should not use the SHA1 hash algorithm. There are known attacks against SHA1 that demonstrate that this hashing algorithm is insecure. In other words, there are known ways to create collisions in which the input text can be predetermined. This opens the possibility for CA certificates to be “spoofed”. Windows supports the following SHA2 hashing algorithms: SHA256, SHA384, and SHA512. While SHA 512 provides greater security, SHA256 is more likely to be supported by applications.
A child CA should be half the life of the parent. In other words, if the Parent CA has a validity period of 20 years, the child CA should have a validity period of 10 years.
CD AutoPlay should be disabled to increase the security of the machines hosting the CA. Although this is less of a security issue today as most servers are Virtual Machines and may not have a CD-ROM drive attached or configured.
By default, Enterprise Admins, Domain Admins, and Local Administrators will have Manage CA permissions on the CA. These permissions should be reduced to a security group that only contains members who are responsible for managing the CA. See the following article for steps to configure this properly:
The following excerpt describes the different types of PKI Hierarchies. For most environments a 2 Tier PKI is recommended. In environments where administration of portions of the PKI must be delegated to different groups or subordination to a public CA is used a 3 Tier PKI would be recommended
Single/One Tier Hierarchy
A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility. The level of security can be enhanced if the CA’s keys are protected by an HSM, but at the expense of higher equipment and management costs.
Two Tier Hierarchy
A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical location, as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s. Cost is increased marginally. I say marginally, because all you need is a hard drive and Windows OS license to implement an Offline Root. Install the hard drive, install your OS, build your PKI hierarchy, and then remove the hard drive and store it in a safe. The hard drive can be attached to existing hardware when CRLs need to be re-signed. A virtual machine could be used as the Root CA, although you would still want to store it on a separate hard drive that can be stored in a safe.
Three Tier Hierarchy
Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
The other reason to have the second tier added is so that if you need to revoke a number of
CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage. And, of course, cost goes up
The DSConfigDN registry key should be configured on Offline CAs. This gives the Offline CAs information on where the forests configuration partition is located in case CRLs or CA certificates are published to AD. Even if you do not use AD (LDAP) as an AIA or CDP repository it is still recommended to store the Root CA Certificate and Policy CA certificates in Active Directory, so they can be deployed to domain members.
To not enable Subject Alternative Names in all Certificate request. If this is enabled any user can potentially request a SAN of their choosing a corticate that they request. See the following link for more information:
To reduce the attack surface of a Certification Authority, no other Server Roles should be installed on the Certification Authority. Also, Certification Authorities should not be installed on Domain Controllers.
Active Directory Certificate Services supports role separation. The following roles can be delegated in a PKI: CA Administrator, Certificate Manager, Backup Operator, and Auditor.
The table below explains the various roles:
Roles and groups
Security permission
Description
CA administrator
Manage CA
Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager
Issue and Manage Certificates
Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snapin.
Backup operator
Back up file and directories Restore file and directories
Perform system backup and recovery. Backup is an operating system feature.
Auditor
Manage auditing and security log
Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role.
The reason for storing Database and Log files on a separate drive is to increase the performance of the CA. Also, since the Database and Log files increase in size over time, there is the potential that they could fill up the system drive resulting in issues for the underlying OS, and the inability to issue new certificates.
The SMTP Exit Module is a monitoring tools that enables the CA Administrator to receive email alerts on various actions that take place on the CA. It is recommended that the SMTP Exit Module be implemented to provide partial coverage for some of the actions that need to be monitored. Additional information on the SMTP Exit Module can be found here:
If OCSP is utilized in the environment, there should be multiple OCSP servers that load balanced. This configuration provides high availability. There is a feature call an Array that simplifies the management of multiple OCSP servers.
In many environment virtualization is used since it reduces cost, increases recovery options, and eases management of systems. However, virtualization does reduce security since there are a larger number of individuals that have access to the environment. If possible Offline CAs should be hosted on physical machines so that they can be physically secured. For Online CAs if virtualization is used, additional security controls should put in place to help increase the security of hosting CAs in this type of environment.
The general guidance is to disable Terminal Services on servers hosting the CA. However, keep in mind that in most environments Terminal Services is required for management of the OS.
If you utilize Delta CRLs, Double Escaping must be enabled on the IIS server that is hosting the HTTP CDP Repository. This is due to the fact that delta CRLs have a + character in their name, which is an escape characters.
To provide high availability for enrollment, Certificate Templates should be available on more then one CA. Keep in mind that high availability for enrollment is not required in many environments. And this configuration does not provide complete high availability for CA services, it only provides high availability for enrolment.
Offline CAs should be protected to prevent someone from creating an unauthorized certificate or having access to the Private Key. Some of these protections include:
Using a Hardware Security Module to protect the private keys.
Using a physical machine that can be secured by locking it in a rack or storing the hard drive in a safe.
Storage of the physical machine should require multiple individuals to get physical access to the machine. Example would be one person having the combination for the safe, and another person having badge access to the room where the safe is stored.
Access to the physical machine should be audited. In other words the individual accessing the physical CA should be required to recorded when they physically access the CA. This auditing should be enforced by the organization. In high security environments approval should be required before physically accessing the Certification Authority.
Root CAs and Intermediate or Policy Certification Authorities that do not regularly issue certificates should be kept offline. By offline we mean that the CA is not connected to a network. See Offline CAs and Physical Security for additional information.
Online Certification Authorities should be regularly updated with Security Updates, they should also be updated with new Services Packs or Upgrades as they are released, in order to keep the OS of the CA in a supported version of Windows. Offline CAs are not vulnerable to network attacks due to the fact that they are not connected to the network, therefore security updates are not required for Offline CAs. However, Offline CAs should be upgraded to the current Service Pack level to ensure that the OS is supported by Microsoft.
The Last logged on User should not be displayed on Certification Authorities. Steps for disabling the display of the last logged on user is available here:
Microsoft recommendations for Maximum Password Age, Minimum Password Length, Password
Complexity, Password History Size, Account Lockouts. For CAs that are part of an Active
Directory domain this will be configured by the Domain Policy. However, Offline Certification Authorities are not connected to a domain, so their password policy needs to be managed via Local Group Policy. For assistance with configuring these settings see:
Documentation should be created for the following scenarios Offline CA Retrieval and Standup, Rebuild of the PKI, Renewals of CA certificates, Disaster Recovery, and Emergency CRL signing.
CAs should be monitored. Monitoring should include up/down monitoring, monitoring of the CA services, monitoring of security events, CRL Freshness, and expiring certificates.
The CA computer object should be a member of the Cert Publishers group in each domain. This gives the CA write permission to the userCertificate attribute on computer and user objects. Which allows the CA to write certificates to this attribute.
Components of the PKI, including Certification Authorities should be installed on the newest operating system. One of the main reasons for this is that each Windows OS has security features to protect against known attacks of the time and by deploying the newest OS you are receiving those protections on you servers that host the PKI environment. The other reason is it increases the amount of time before you have to upgrade the OS. The latest OS at the time of writing is Windows Server 2016.
The CA should be regularly backed up. The CA can be backed up through System State backups or through a CA specific backup. Online CAs should be backed up every day. Offline CAs should be backed up whenever their configuration changes. Additionally, private keys should be backed up separately and stored in a secured and restricted location.
Enroll and Autoenrollment permissions on Certificate Templates should be restricted to only those user or computers that should be enrolling or autoenrolling for this type of certificate
Windows supports both HTTP and LDAP locations for AIA and CDP repositories. The best practice is to use HTTP repositories and not LDAP repositories. HTTP locations should be identified with DNS name or in other words a FQDN. An example would be pki.fourthcoffee.com. Additionally, the DNS name should not be the name of a server or computer. The DNS name should be an alias such as pki.fourthcoffee.com or certs.fourthcoffee.com that can easily be redirected if the hosting environment changes.
HTTP repositories should be highly available. This means that multiple Web Servers should be load balanced to provide redundancy. Also, if possible there should be an HTTP repository available in each site so that clients get more rapid responses. This configuration would require a load balancer that can give site specific responses to the client.
Additionally, multiple HTTP locations can be used to increase the availability of these locations.
xdot509.blog 