It came to our attention that the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure whitepaper provides wrong guidance in section Import the Root CA Certificate and CRL into an Intermediate CA from a Batch File. The current documentation recommends that the CRL published by the Root CA is to be added to the Root certificate store.

There are two corrections needed for the commands in step #4 in the Import the Root CA Certificate and CRL into an Intermediate CA from a Batch File section:

One of the improvements of the Windows Server 2008 Certification authority is the support for Cryptography Next Generation (CNG) with Elliptic Curve Cryptography (ECC).

I have described the CNG capabilities in my Certificate Server Enhancements in Windows Server codename "Longhorn" whitepaper but after reviewing the paper recently I noticed that it does not exactly explain how to set up a new Windows Server 2008 CA with a CNG certificate.

Also, the reference provided in paragraph "Configuring setup using a CAPolicy.inf file" is outdated and refers to an invalid page. The PKCS #1: RSA Cryptography Standard is now documented at http://www.rsa.com/rsalabs/node.asp?id=2125.

To set up a CA with a CNG certificate, perform the normal "Active Directory Certificate Services" setup procedure until you reach the Configure Cryptography for CA wizard page. Now you have to decide which Cryptography or Key Provider is used by the CA. All providers that have a #-sign as prefix in their name represent key storage provider and can support CNG algorithms.

Even if you don't have a requirement for a CNG certificate today, you should select a key storage provider that is supporting CNG. Luckily, the RSA#Microsoft Software Key Storage Provider is the default setting so that you have greater flexibility regarding hash algorithm configuration compared to cryptographic service providers. How to change the hash algorithm for a key storage provider is described in the chapter "Configuring the Cryptographic Algorithms used by the CA" in the Certificate Server Enhancements in Windows Server codename "Longhorn" whitepaper.

Many Windows error messages provide a hexadecimal error code, for example 0x8007267C. This code can provide helpful information. But how to translate it into a readable error message?

At least two commands can be used to decode an error code:

· certutil -error [Code]

· err.exe [Code]

For example

certutil -error 0x8007267C

Certutil is part of all Windows server stock keeping units (SKU) and Windows Vista. The err executable is available from the Microsoft Download center.

By default, Windows is caching Certificate Revocation Lists (CRL) and CA certificates to quickly verify certificate chains. The downside of this behavior is that a newer CRL is not picked up by the client until the locally cached CRL has expired.

Windows versions before Windows Vista do not support deletion or a forced update of the CRL cache.

You can view what is in your current CRL cache with the following command:

certutil -URLcache CRL

On Windows Vista, CAPI 2.0 has support to set a expiry date for the CRL and OCSP cache. You can use certutil to set a date and time when all cache entries become invalid. The following commands require administrative permission on the system.

To see when the cache was invalidated the last time, perform this command:

certutil –getreg chain\ChainCacheResyncFiletime

Note: If the ChainCacheResyncFiletime was never set manually before, the registry key does not exist and the following error message is shown:

CertUtil: -getreg command FAILED: 0x80070002 (WIN32: 2)

CertUtil: The system cannot find the file specified.

The error can be ignored because default CRL caching takes place in this case.

If the @now parameter is used, all cached entries are invalidated immediately.

certutil -setreg chain\ChainCacheResyncFiletime @now

To disable temporarily the cache until after now plus 3 days and 6 hours, use this command. Setting the registry value to a future date implies that no cache entries will be used until after the date specified. The value of such a configuration is questionable.

certutil –setreg chain\ChainCacheResyncFiletime @now+3:6

To delete a registry value:

certutil –delreg chain\ChainCacheResyncFiletime