Return to Answer

Decommissioning a PKI Tree

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.

• 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.

• 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)

• 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

• 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)

CNG private key storage vs CSP storage

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 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

(source)

Cross Certificate Distribution Points

• Windows AC Certificate Services enabled this via the [CrossCertificateDistributionPointsExtension] CAPolicy.inf entry

PKCS#1 v2.1

This is enabled when the CAPolicy.inf file has AlternateSignatureAlgorithm=1

• 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)

Finally one should know that installing AD Certificate Services isn't as simple as adding the role. You should check this VBS Installation script and ensure file CAPolicy.inf should be edited as needed for your environment

Misc: AIA differences in Windows 2000 and Windows 2003

Note that there is a change in behavior between Windows 2000 and 2003 CAs. The AKI extension of certificates issued by Windows CAs differs between Windows 2000 and Windows Server 2003. By default, the following information is stored in the AIA extension of issued certificates.

• Windows 2000 The AIA extension of certificates issued by the CA includes the LDAP DN of the issuing CA (Issuer name), the serial number of the issuing CA’s certificate, and the key hash of the CA certificate’s public key.

• Windows Server 2003 The AIA extension of certificates issued by the CA only includes a hash of the public key of the issuing CA, also known as the Key-ID.

The change in behavior is due to chaining errors that could occur when a CA’s certificate was renewed. The default Windows 2000 behavior could result in incomplete chains if the CA certificate used to sign the issued certificate was not available to the client. With the Windows Server 2003 default behavior, if the CA was renewed with the same key pair, any CA certificate for the issuing CA that uses the same key pair could be included in the certificate chain.

You can imitate the old behavior by running this command

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Misc: Listing certificates in AD

This command will list the certificates published in Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

Define a policy in issued certificates

The parent CA defines whether or not to allow CA certificate policies from sub CAs. It is possible to define this setting when a issuer or application policy needs to be included in a sub CA.

Example polices include an EKU for SmartCards, Authentication, or SSL/Server authentication.

Cross Certificate Distribution Points

PKCS#1 v2.1

• 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)