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 Certification Authorities should be configured to not publish Delta CRLs
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 and SMB should not be used for AIA and CDP locations
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.
CA Certificates and issued certificates that use RSA should have a key length of 2048 or larger.
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.
Offline CAs should not be a member of an Active Directory Domain.
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.
Root Certification Authorities should not contain Authority Information Access or CRL Distribution Point location defined in their certificate.
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.
AIA and CDP locations should use the proper variables
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.
Offline CA CRLs Validity Periods
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.
Online CA CRLs Validity Periods
Online CAs should have CRL validity periods that due not exceed 1 week or 7 days. This is due to the fact that end entity certificates may become untrusted and need to be revoked. Using a period of 7 days or shorter ensures a reasonable amount of time to notify “clients” after a CRL has been revoked. For additional information and guidance on CRL Validity periods see: https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki–design–considerationscertificate–revocation–and–crl–publishing–strategies/.
SHA2 Hash Algorithm
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.
CA Validity Period
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
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.
Windows Firewall Enabled
Windows Firewall should be enabled on all Certification Authorities that are connected to a network.
CA Admin Permissions
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:
PKI Hierarchy
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
DSConfigDN
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.
Subject Alternative Names
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:
Server Roles on a Certification Authority
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.
Auditing
In order for auditing to be enabled, Auditing must be enabled on the CA and Auditing for Object Access must be enabled in policy. For Domain joined machines this policy can be managed by Group Policy. For Offline CAs this policy must be managed in the Local Group Policy. See the following article for steps to configure auditing: https://docs.microsoft.com/en-us/archive/blogs/xdot509/installing-a-two-tier-pki-hierarchy-in-windows-server-2012-part-viii-pki-security
Role separation should be utilized
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. |
https://technet.microsoft.com/en-us/library/cc732590(v=WS.11).aspx
CA Database and Log Files should not be stored on the system drive
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.
SMTP Exit Module
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:
https://docs.microsoft.com/en-us/archive/blogs/xdot509/operating-a-pki-smtp-exit-module
OCSP High Availability
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.
Virtualization
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.
Terminal Services Disabled
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.
Delta CRLs require Double Escaping to be enabled on HTTP CDP Repository
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.
Templates on multiple CAs
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 and Physical Security
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.
Certification Authorities that do not regularly issue certificates should be kept offline.
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.
OS updates and security updates
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.
Last Logged on User
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:
Password Configuration (Maximum Password Age, Minimum Password Length, Password Complexity, Password History Size, Account Lockouts)
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:
The following are their current Microsoft Recommendations for these settings:
- Enforce password history: 24 passwords
- Minimum password length: 14 characters
- Password must meet complexity requirement: Enabled
- Minimum password age: 1 day
- Maximum password age: 60 days
- Store passwords using reversible encryption: Disabled
- Reset account lockout counter after: 15 Minutes
- Account lockout threshold: 10 invalid logon attempts
- Account lockout duration:15 minutes
Documentation including documentation for Offline CA Retrieval and Standup, Rebuild of the PKI, Renewals of CA certificates, Disaster Recovery, and Emergency CRL signing
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.
Monitoring
CAs should be monitored. Monitoring should include up/down monitoring, monitoring of the CA services, monitoring of security events, CRL Freshness, and expiring certificates.
Cert Publishers Group
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.
Latest OS Version
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.
CA Certificate Renewals
There should a CA Certificate plan in place. The following resource is available to assist you in the planning of CA Certificate renewals in your environment: https://blogs.technet.microsoft.com/xdot509/2013/05/27/operating–a–windows–pkicertification–authority–certificate–lifecycle–and–renewals/
Backup including backup encryption and private key backups
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.
Certificate Template Permissions
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
Enrolled Supplied Subject
For certificate templates that allow the enrollee to provide the subject or subject alternative name, certificate manager approval should be required.
For example if the Certificate Template is configured for the Subject to be “Supplied in the request”
Then the Certificate Template should be require to have “Certificate manager approval”, configured.
AIA and CDP Best Practices
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.
Is there anything I missed? If so let me know, contact me at https://xdot509.blog/contact/.
-Chris
xdot509.blog 