Storing the CA's Private Key
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.
OK: 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
Meh: 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
Key Length
- A general purpose Root CA 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.
Choosing a Hash
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)
Choosing a Cryptographic Provider
- I'm not sure which one to choose so I'll post this link to a list of providers
CRL Distribution Point
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.
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.
Don't use 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.
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.
Note: CRL distribution over HTTP with ETAG Support may cause issues with IE6 when using Windows 2003 / IIS6, where the TCP connection is continually reset.
- (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
Authority Information Access
A self-signed root CA should not list any AIA locations
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.
Cross Certificate Distribution Points
- Windows supports [CrossCertificateDistributionPointsExtension]
High Security/Suite B Deployments
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 Provideras well as the384key size andSHA384as 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_P521is 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.
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)
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