Return to Answer

Note: This is a (very very long) compendium of various recommendations and actions that Microsoft, NIST, and other well respected PKI and cryptography experts have said. If you see something that requires even the slightest revision, do let me know.

Before I get into configuring the CA and its subs, it's good to know that even though MSFT's CryptoAPI requires a self-signed root, some non-MSFT software may follow RFC 3280 and allow any CA to be the trusted root for validation purposes. One reason may be that the non-MSFT software prefers a lower key length.

• Best: Store the key on a HSM that supports key counting. Every time the CA's private key is used, the counter will be increased. This improves your audit profile. Look for FIPS140 Level 3 or 4

• Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

• Acceptable: Store the private key in Windows DPAPI. Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials. See also: How to enumerate DPAPI and Roaming Credentials

• Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

• Root CAs that supports legacy apps should never be larger than 2048 bits. Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes. Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

• The NIST recommends 2048 or 3072 bits. ECC is supported, though it may cause issues with device interoperability.

• Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

• Mobile clients have issues (High CPU) or incompatibility with large keys

The algorithm & Key length can have a bearing on how long you want certificates to be valid, because they effectively determine how long it might take an attacker crack, ie the stronger the cryptography, the longer you might be prepared to have certificates valid for

• You may want to imitate the Federal PKI Management Authority and set up two PKI roots. One modern SHA-256 for all devices that support it, and one legacy SHA-1. Then use cross certificates to map between the two deployments.

• Review this SHA-2 compatibility list for Microsoft software

As of 2012, this is required if you use MD5 as a hash. It's still a good idea if SHA1 or greater is used. Also see this Windows 2008R2 "how to" for more information.

Best Practice: Although it is possible to put freeform text into this field (see notice below), the ideal solution is to use a URL. This allows the policy to be updated without reissuing the certificates, it also prevents unneeded bloating of the certificate store.

Application Policies is an optional Microsoft convention. If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.

• This is optional in a Root CA, and if done incorrectly it may expose your private key.

• All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

• It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

• Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done. This permits the certificate to be revoked.

Getting the CRL "right" is pretty important since it's up to each application to do the CRL check. For example, smart card logon on domain controllers always enforce the revocation check and will reject a logon event if the revocation check cannot be performed or fails.

• A self-signed root CA should not list any CDPs. Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode). If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

• Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

• Another reason to not use LDAP is because the revocation window to be smaller. When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update. Oftentimes this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked. 'Todo: the new recommended CRL refresh time is: ?????`

• Make all the URLs highly available (aka don't include LDAP for external hosts). Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min. I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

• Monitor the size of your CRL. If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

Since renewing a CA cert causes a new/blank CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly.  More info

If using a CRL, don't sign the CRL with MD5. It's also a good idea to add randomization to the CRL signing key.

A typical stand-alone CA certificate will contain permissions to create Digital Signatures, Certificate Signing, and CRL signing as key values. This is part of the issue with the FLAME security issue.

Here is a sample user dialog for S/MIME. Expect similar UIs for Brower based certificates. Notice how the Issuer name isn't user friendly.

• XP clients and many non-windows systems do not support this new signature format. This should be disabled if older clients need to be supported. More Info

• I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

If you enroll Certificate Template v3, the private key goes into the CNG private key storage on the client computer. If you enroll Certificate Template v2 or v1, the private key goes into CSP storage. The certificates will be visible to all applications in both cases, but not their private keys - so most applications will show the certificate as available, but will not be able to sign or decrypt data with the associated private key unless they support CNG storage.

You cannot distinguish between CNG and CSP storages by using the Certificate MMC. If you want to see what storage a particular certificate is using, you must use CERTUTIL -repairstore my * (or CERTUTIL -user -repairstore my *) and take a look at the Provider field. If it is saying "... Key Storage Provider", than it is CNG while all other providers are CSP.

If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP. The following is my experience-based list of what does not support CNG - you cannot find an authoritative list anywhere, so this arises from my investigations over time:

• EFS - User Encryption Certificates - not supported in Windows Vista/2008, supported in Windows 7/2008R2
• VPN/WiFi Client (EAPTLS, PEAP Client) - User or computer certificate authentication - not supported in Windows 7/2008R2, supported in Windows 2012/8.1
• Network Device Enrollment Service Registration Authority Certificates (NDES) - A legacy CSP (Cryptographic Service Provider) must be installed
• TMG 2010 - Server certificates on web listeners
• Outlook - User email certificates for signatures or encryption - not supported in Outlook 2003, supported in Outlook 2007 on Windows Vista
• Kerberos - Domain controller certificates - supported in Windows Vista/2008
• System Center Operations Manager 2007 R2
• System Center Configuration Manager 2007 R2
• SQL Server (all versions currently require a certificate that uses a legacy Cryptographic Storage Provider)
• Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility are listed here and here

If you deploy two PKI trees, with the intent to decommission the legacy tree at some point (where all old devices have become obsolete or upgraded) it may be a good idea to set the CRL Next Update field to Null. This will (should?) prevent the continual polling for new CRLS to the clients. The reasoning is that once the PKI is decommissioned, there will be no more administration, and no more revoked certs. All remaining certs are simply left to expire.

Note: This is a (very long) compendium of recommendations and actions from Microsoft, NIST, and other well respected PKI and cryptography experts. If you see something that requires even the slightest revision, do let me know.

Before I get into configuring the CA and its subs, it's good to know that even though MSFT's CryptoAPI requires a self-signed root, some non-MSFT software may follow RFC 3280 and allow any CA to be the trusted root for validation purposes. One reason may be that the non-MSFT software prefers a lower key length.

• Best: Store the key on a HSM that supports key counting. Every time the CA's private key is used, the counter will be increased. This improves your audit profile. Look for FIPS140 Level 3 or 4

• Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

• Acceptable: Store the private key in Windows DPAPI. Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials. See also: How to enumerate DPAPI and Roaming Credentials

• Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

• Root CAs that supports legacy apps should never be larger than 2048 bits. Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes. Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

• The NIST recommends 2048 or 3072 bits. ECC is supported, though it may cause issues with device interoperability.

• Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

• Mobile clients have issues (High CPU) or incompatibility with large keys

The algorithm & key length can have a bearing on how long you want certificates to be valid, because they effectively determine how long it might take an attacker crack, ie the stronger the cryptography, the longer you might be prepared to have certificates valid for

• You may want to imitate the Federal PKI Management Authority and set up two PKI roots. One modern SHA-256 for all devices that support it, and one legacy SHA-1. Then use cross certificates to map between the two deployments.

• Review this SHA-2 compatibility list for Microsoft software

As of 2012, this is required if you use MD5 as a hash. It's still a good idea if SHA1 or greater is used. Also see this Windows 2008R2 "how to" for more information.

Best Practice: Although it is possible to put freeform text into this field (see notice below), the ideal solution is to use a URL. This allows the policy to be updated without reissuing the certificates, it also prevents unneeded bloating of the certificate store.

Application Policies is an optional Microsoft convention. If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.

• This is optional in a Root CA, and if done incorrectly it may expose your private key.

• All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

• It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

• Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done. This permits the certificate to be revoked.

Getting the CRL "right" is pretty important since it's up to each application to do the CRL check. For example, smart card logon on domain controllers always enforce the revocation check and will reject a logon event if the revocation check cannot be performed or fails.

• A self-signed root CA should not list any CDPs. Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode). If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

• Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

• Another reason to not use LDAP is because the revocation window to be smaller. When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update. Often this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked. 'Todo: the new recommended CRL refresh time is: ?????’

• Make all the URLs highly available (aka don't include LDAP for external hosts). Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min. I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

• Monitor the size of your CRL. If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

Since renewing a CA cert causes a new/blank CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly. More info

If using a CRL, don't sign the CRL with MD5. It's also a good idea to add randomization to the CRL signing key.

A typical stand-alone CA certificate will contain permissions to create Digital Signatures, Certificate Signing, and CRL signing as key values. This is part of the issue with the FLAME security issue.

Here is a sample user dialog for S/MIME. Expect similar UIs for Browser based certificates. Notice how the Issuer name isn't user friendly.

• XP clients and many non-windows systems do not support this new signature format. This should be disabled if older clients need to be supported. More Info

• I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

If you enroll Certificate Template v3, the private key goes into the CNG private key storage on the client computer. If you enroll Certificate Template v2 or v1, the private key goes into CSP storage. The certificates will be visible to all applications in both cases, but not their private keys - so most applications will show the certificate as available, but will not be able to sign or decrypt data with the associated private key unless they support CNG storage.

You cannot distinguish between CNG and CSP storages by using the Certificate MMC. If you want to see what storage a particular certificate is using, you must use CERTUTIL -repairstore my * (or CERTUTIL -user -repairstore my *) and take a look at the Provider field. If it ends " Key Storage Provider", than it is CNG while all other providers are CSP.

If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP. The following is my experience-based list of what does not support CNG:

• EFS - not supported in Windows Vista/2008, supported in Windows 7/2008R2
• ADFS - Token Signing, Service Communication Certificates - not supported in Windows 8.1/2012R2, supported in Windows 10/2016
• VPN/WiFi Client (EAPTLS, PEAP) user/computer - not supported in Windows 7/2008R2, supported in Windows 2012/8.1

• Network Device Enrollment Service Registration Authority Certificates (NDES) - A legacy CSP (Cryptographic Service Provider) must be installed
• TMG 2010 - Server certificates on web listeners
• Outlook - User email certificates for signatures or encryption - not supported in Outlook 2003, supported in Outlook 2007 on Windows Vista
• Kerberos - Domain controller certificates - supported in Windows Vista/2008
• System Center Operations Manager 2007 R2
• System Center Configuration Manager 2007 R2
• SQL Server (all versions currently require a certificate that uses a legacy Cryptographic Storage Provider)
• Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility is listed here and here

If you deploy two PKI trees, with the intent to decommission the legacy tree at some point (where all old devices have become obsolete or upgraded) it may be a good idea to set the CRL Next Update field to Null. This will (should?) prevent the continual polling for new CRLS to the clients. The reasoning is that once the PKI is decommissioned, there will be no more administration, and no more revoked certs. All remaining certs are simply left to expire.

If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP. The following is my experience-based list of what does not support CNG - you cannot find an authoritative list anywhere, so this arrises from my investigations over time:

• EFS Not supported in Windows 2008/Vista, Supported in Windows 7/2008R2

• user encryption certificates

• VPN/WiFi Client (EAPTLS, PEAP Client)

• Windows 2008/7 Not supported with user or computer certificate authentication

• TMG 2010 server certificates on web listeners

• Outlook 2003 user email certificates for signatures or encryption

• Kerberos Windows 2008/Vista- DC certificates

• System Center Operations Manager 2007 R2

• System Center Configuration Manager 2007 R2

• SQL Server 2008 R2-

• Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility is listed here (in Czech, though Chrome handles the auto-translation well)

If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP. The following is my experience-based list of what does not support CNG - you cannot find an authoritative list anywhere, so this arises from my investigations over time:

• EFS - User Encryption Certificates - not supported in Windows Vista/2008, supported in Windows 7/2008R2
• VPN/WiFi Client (EAPTLS, PEAP Client) - User or computer certificate authentication - not supported in Windows 7/2008R2, supported in Windows 2012/8.1
• Network Device Enrollment Service Registration Authority Certificates (NDES) - A legacy CSP (Cryptographic Service Provider) must be installed
• TMG 2010 - Server certificates on web listeners
• Outlook - User email certificates for signatures or encryption - not supported in Outlook 2003, supported in Outlook 2007 on Windows Vista
• Kerberos - Domain controller certificates - supported in Windows Vista/2008
• System Center Operations Manager 2007 R2
• System Center Configuration Manager 2007 R2
• SQL Server (all versions currently require a certificate that uses a legacy Cryptographic Storage Provider)
• Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility are listed here and here

• Best: Store the key on a HSM that supports key counting. Every time the CA's private key is used, the counter will be increased. This improves your audit profile. Look for FIPS140 Level 3 or 4

• Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

• Acceptable: Store the private key in Windows DPAPI. Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials. See also: How to enumerate DPAPI and Roaming Credentials

• Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

• Root CAs that supports legacy apps should never be larger than 2048 bits. Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes. Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

• The NIST recommends 2048 or 3072 bits. ECC is supported, though it may cause issues with device interoperability.

• Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

• Mobile clients have issues (High CPU) or incompatibility with large keys

If you're concerned about compatibility, set the expiration date below 2038. This is due to systems that encode a data as seconds since January 1st 1970 over a signed 32 bit integer. Read more about this issue here.

• You may want to imitate the Federal PKI Management Authority and set up two PKI roots. One modern SHA-256 for all devices that support it, and one legacy SHA-1. Then use cross certificates to map between the two deployments.

• Review this SHA-2 compatibility list for Microsoft software

• Windows 2003 and XP clients may need a patch for SHA2 Algorithms which include SHA256, SHA384, and SHA512. See more technical information

• Authenticode and S/MIME with SHA2 hashing is not supported on XP or 2003

• "Regarding SHA-224 support, SHA-224 offers less security than SHA-256 but takes the same amount of resources. Also SHA-224 is not generally used by protocols and applications. The NSA's Suite B standards also do not include it." source

• "Do not use SHA2 suite anywhere in the CA hierarchy if you plan to have XP either trust the certificate, validate the certificate, use the certificate in chain validation, or receive a certificate from the CA. Even though XP SP3 allows validation of certiifcates that use SHA2 in the CA hierarchy, and KB 968730 allows limited enrollment of certificates that are signed by a CA using SHA2, any use of discrete signatures blocks out XP entirely." (source)

• View this list of providers for more information

As of 2012, this is required if you use MD5 as a hash. It's still a good idea if SHA1 or greater is used. Also see this Windows 2008R2 "how to" for more information.

A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it issues. It describes how the certificate policy of the organization is interpreted in the context of the system architecture of the organization and its operating procedures. The IT department is responsible for preparing and maintaining the certificate practice statement. (source)

For assistance writing a CPS statement, here is a Microsoft produced "Job Aid"

Also known as issuance policies, or assurance policies (in MSFT), this is a self defined OID that describes the amount of trust one should put into your certificate (high, med, low, etc). See this StackExchange answer for how to properly use this field.

Application Policies is an optional Microsoft convention. If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

• This is optional in a Root CA, and if done incorrectly it may expose your private key.

• All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

• It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

• Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done. This permits the certificate to be revoked.

• A self-signed root CA should not list any CDPs. Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode). If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

• Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

• Another reason to not use LDAP is because the revocation window to be smaller. When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update. Oftentimes this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked. 'Todo: the new recommended CRL refresh time is: ?????`

• Make all the URLs highly available (aka don't include LDAP for external hosts). Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min. I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

• Monitor the size of your CRL. If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

• (Optional) Enable Freshest CRL: This non-critical extension lists the issuers and locations from which to retrieve the delta CRLs. If the “Freshest CRL” attribute is neither present in the CRL nor in the certificate, then the base CRL will be treated as a regular CRL, not as part of a base CRL/delta CRL pair.

The Microsoft CA does not put the “Freshest CRL” extension into issued certificates. However, it is possible to add the “Freshest CRL” extension to an issued certificate. You would have to write code to add it to the request, write a custom policy module, or use certutil –setextension on a pending request. For more information about advanced certificate enrollment, see the “Advanced Certificate Enrollment and Management” documentation on the Microsoft Web site

Since renewing a CA cert causes a new/blank CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly. More info

If using a CRL, don't sign the CRL with MD5. It's also a good idea to add randomization to the CRL signing key.

• A self-signed root CA should not list any AIA locations (see reason here)

• A maximum of five URLs are allowed in the AIA extension for every certificate in the certificate chain. In addition, a maximum of 10 URLs for the entire certificate chain is also supported. This limitation on the number of URLs was added to mitigate the potential use of “Authority Info Access” references in denial of service attacks.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

The OCSP responder is conventionally located at: http://<fqdn of the ocsp responder>/ocsp. This url needs to enabled in the AIA. See these instructions for Windows.

Do know that full OCSP validation is off by default (though it should be "on" for EV certs according to the specification). In addition, enabling OCSP checking does add latency to the initial connection

More secure systems will want to enable OCSP monitoring on the client or the server side

• Beware of certificates without the Certificate Policies extension as it can complicate the Policy Tree. See RFC 5280 for more information

• Know that policy mappings can replace other policies in the path

• There is a special policy called anypolicy that alters processing

• There are extensions that alter anypolicy

• If you use certificate policies, be sure to mark them as critical otherwise the computed valid_policy_tree becomes empty, turning the policy into a glorified comment.

In contrast with RFC 5280 that states “in general, [sic] the EKU extension will appear only in end entity certificates." it's a good idea to put constraints on the CA Key usage.

The MSFT smart card implementation requires either of the following EKUs and possibly a hotfix

If you're interested in having any EKU restrictions you should see this answer regarding OIDs and this regarding contrained certificates

The Basic Constraint should describe if the certificate is an "end entity" or not. Adding a path constraint to a intermediate CA may not work as expected since it's an uncommon configuration and clients may not honor it.

• To limit the types of certificates a subCA can offer see this link, and this one

• If qualified subordination is done, revoking a cross signed root may be difficult since the roots don't update the CRLs frequently.

Note If a certificate’s AKI extension contains a KeyID, CryptoAPI requires the issuer certificate to contain a matching SKI. This differs from RFC 3280 where SKI and AKI matching is optional. (todo: Why would someone choose to implement this?)

People will interact with your certificate when importing it, reviewing imported certificates, and troubleshooting. MSFT's recommended practice and requirement is that the root has a meaningful name that identifies your organisation and not something abstract and common like CA1.

Here is a sample user dialog for S/MIME. Expect similar UIs for Brower based certificates. Notice how the Issuer name isn't user friendly.

• Here is information regarding the Suite B algorithms supported in Windows 2008 and R2

  ALGORITHM SECRET TOP SECRET

  Encryption: Advanced Standard (AES) 128 bits 256 bits

  Digital Signature: Elliptic Curve Digital Signature Algorithm (ECDSA) 256 bit curve. 384 bit curve

  Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) 256 bit curve. 384 bit curve

  Hashing: Secure Hash Algorithm (SHA) SHA-256 SHA-384

• For Suite B compliance, the ECDSA_P384#Microsoft Software Key Service Provider as well as the 384 key size and SHA384 as the hash algorithm may also be selected if the level of classification desired is Top Secret. The settings that correspond with the required level of classification should be used. ECDSA_P521 is also available as an option. While the use of a 521 bit ECC curve may exceed the cryptographic requirements of Suite B, due to the non-standard key size, 521 is not part of the official Suite B specification.

• XP clients and many non-windows systems do not support this new signature format. This should be disabled if older clients need to be supported. More Info

• I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

The Windows Server 2003 CA does not enforce encryption on the ICertRequest or ICertAdmin DCOM interfaces by default. Normally, this setting is not required except in special operational scenarios and should not be enabled. Only Windows Server 2003 machines by default support DCOM encryption on these interfaces. For example, Windows XP clients will not by default enforce encryption on certificate request to a Windows Server 2003 CA. source

More information on CNG compatibility is listed here (in Czech, though Chrome handles the auto-translation well)

If you plan on giving users a second smart card for authentication, use a second issuer CA for that. Reason: Windows 7 requirements

More information on PKI decommissioning available here

• Best: Store the key on a HSM that supports key counting. Every time the CA's private key is used, the counter will be increased. This improves your audit profile. Look for FIPS140 Level 3 or 4

• Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

• Acceptable: Store the private key in Windows DPAPI. Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials. See also: How to enumerate DPAPI and Roaming Credentials

• Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

• Root CAs that supports legacy apps should never be larger than 2048 bits. Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes. Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

• The NIST recommends 2048 or 3072 bits. ECC is supported, though it may cause issues with device interoperability.

• Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

• Mobile clients have issues (High CPU) or incompatibility with large keys

If you're concerned about compatibility, set the expiration date below 2038. This is due to systems that encode a data as seconds since January 1st 1970 over a signed 32 bit integer. Read more about this issue here.

• You may want to imitate the Federal PKI Management Authority and set up two PKI roots. One modern SHA-256 for all devices that support it, and one legacy SHA-1. Then use cross certificates to map between the two deployments.

• Review this SHA-2 compatibility list for Microsoft software

• Windows 2003 and XP clients may need a patch for SHA2 Algorithms which include SHA256, SHA384, and SHA512. See more technical information

• Authenticode and S/MIME with SHA2 hashing is not supported on XP or 2003

• "Regarding SHA-224 support, SHA-224 offers less security than SHA-256 but takes the same amount of resources. Also SHA-224 is not generally used by protocols and applications. The NSA's Suite B standards also do not include it." source

• "Do not use SHA2 suite anywhere in the CA hierarchy if you plan to have XP either trust the certificate, validate the certificate, use the certificate in chain validation, or receive a certificate from the CA. Even though XP SP3 allows validation of certiifcates that use SHA2 in the CA hierarchy, and KB 968730 allows limited enrollment of certificates that are signed by a CA using SHA2, any use of discrete signatures blocks out XP entirely." (source)

• View this list of providers for more information

As of 2012, this is required if you use MD5 as a hash. It's still a good idea if SHA1 or greater is used. Also see this Windows 2008R2 "how to" for more information.

A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it issues. It describes how the certificate policy of the organization is interpreted in the context of the system architecture of the organization and its operating procedures. The IT department is responsible for preparing and maintaining the certificate practice statement. (source)

For assistance writing a CPS statement, here is a Microsoft produced "Job Aid"

Also known as issuance policies, or assurance policies (in MSFT), this is a self defined OID that describes the amount of trust one should put into your certificate (high, med, low, etc). See this StackExchange answer for how to properly use this field.

Application Policies is an optional Microsoft convention. If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

• This is optional in a Root CA, and if done incorrectly it may expose your private key.

• All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

• It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

• Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done. This permits the certificate to be revoked.

• A self-signed root CA should not list any CDPs. Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode). If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

• Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

• Another reason to not use LDAP is because the revocation window to be smaller. When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update. Oftentimes this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked. 'Todo: the new recommended CRL refresh time is: ?????`

• Make all the URLs highly available (aka don't include LDAP for external hosts). Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min. I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

• Monitor the size of your CRL. If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

• (Optional) Enable Freshest CRL: This non-critical extension lists the issuers and locations from which to retrieve the delta CRLs. If the “Freshest CRL” attribute is neither present in the CRL nor in the certificate, then the base CRL will be treated as a regular CRL, not as part of a base CRL/delta CRL pair.

The Microsoft CA does not put the “Freshest CRL” extension into issued certificates. However, it is possible to add the “Freshest CRL” extension to an issued certificate. You would have to write code to add it to the request, write a custom policy module, or use certutil –setextension on a pending request. For more information about advanced certificate enrollment, see the “Advanced Certificate Enrollment and Management” documentation on the Microsoft Web site

Since renewing a CA cert causes a new/blank CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly. More info

If using a CRL, don't sign the CRL with MD5. It's also a good idea to add randomization to the CRL signing key.

• A self-signed root CA should not list any AIA locations (see reason here)

• A maximum of five URLs are allowed in the AIA extension for every certificate in the certificate chain. In addition, a maximum of 10 URLs for the entire certificate chain is also supported. This limitation on the number of URLs was added to mitigate the potential use of “Authority Info Access” references in denial of service attacks.

• Don't use HTTPS and LDAPS. These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

The OCSP responder is conventionally located at: http://<fqdn of the ocsp responder>/ocsp. This url needs to enabled in the AIA. See these instructions for Windows.

Do know that full OCSP validation is off by default (though it should be "on" for EV certs according to the specification). In addition, enabling OCSP checking does add latency to the initial connection

More secure systems will want to enable OCSP monitoring on the client or the server side

• Beware of certificates without the Certificate Policies extension as it can complicate the Policy Tree. See RFC 5280 for more information

• Know that policy mappings can replace other policies in the path

• There is a special policy called anypolicy that alters processing

• There are extensions that alter anypolicy

• If you use certificate policies, be sure to mark them as critical otherwise the computed valid_policy_tree becomes empty, turning the policy into a glorified comment.

In contrast with RFC 5280 that states “in general, [sic] the EKU extension will appear only in end entity certificates." it's a good idea to put constraints on the CA Key usage.

The MSFT smart card implementation requires either of the following EKUs and possibly a hotfix

If you're interested in having any EKU restrictions you should see this answer regarding OIDs and this regarding contrained certificates

The Basic Constraint should describe if the certificate is an "end entity" or not. Adding a path constraint to a intermediate CA may not work as expected since it's an uncommon configuration and clients may not honor it.

• To limit the types of certificates a subCA can offer see this link, and this one

• If qualified subordination is done, revoking a cross signed root may be difficult since the roots don't update the CRLs frequently.

Note If a certificate’s AKI extension contains a KeyID, CryptoAPI requires the issuer certificate to contain a matching SKI. This differs from RFC 3280 where SKI and AKI matching is optional. (todo: Why would someone choose to implement this?)

People will interact with your certificate when importing it, reviewing imported certificates, and troubleshooting. MSFT's recommended practice and requirement is that the root has a meaningful name that identifies your organisation and not something abstract and common like CA1.

Here is a sample user dialog for S/MIME. Expect similar UIs for Brower based certificates. Notice how the Issuer name isn't user friendly.

• Here is information regarding the Suite B algorithms supported in Windows 2008 and R2

  ALGORITHM SECRET TOP SECRET

  Encryption: Advanced Standard (AES) 128 bits 256 bits

  Digital Signature: Elliptic Curve Digital Signature Algorithm (ECDSA) 256 bit curve. 384 bit curve

  Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) 256 bit curve. 384 bit curve

  Hashing: Secure Hash Algorithm (SHA) SHA-256 SHA-384

• For Suite B compliance, the ECDSA_P384#Microsoft Software Key Service Provider as well as the 384 key size and SHA384 as the hash algorithm may also be selected if the level of classification desired is Top Secret. The settings that correspond with the required level of classification should be used. ECDSA_P521 is also available as an option. While the use of a 521 bit ECC curve may exceed the cryptographic requirements of Suite B, due to the non-standard key size, 521 is not part of the official Suite B specification.

• XP clients and many non-windows systems do not support this new signature format. This should be disabled if older clients need to be supported. More Info

• I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

The Windows Server 2003 CA does not enforce encryption on the ICertRequest or ICertAdmin DCOM interfaces by default. Normally, this setting is not required except in special operational scenarios and should not be enabled. Only Windows Server 2003 machines by default support DCOM encryption on these interfaces. For example, Windows XP clients will not by default enforce encryption on certificate request to a Windows Server 2003 CA. source

More information on CNG compatibility is listed here (in Czech, though Chrome handles the auto-translation well)

If you plan on giving users a second smart card for authentication, use a second issuer CA for that. Reason: Windows 7 requirements

More information on PKI decommissioning available here