Lots of different systems and platforms use certificates and Public Key Infrastructure (PKI). Many companies have decided to implement an internal Certification Authority to issue certificates to computers, users, and other Certification Authorities. When you decide to implement an internal PKI you’ll need to plan out the deployment, including end-user and CA certificate properties.
One of the most important decisions you will make about your certificates is the key size for your Root Certification Authority (CA). If you follow my guidance on deploying an offline Root CA then you know that this top-level certification authority should have a long-life certificate, perhaps 5 or 10 years. And even though it is an offline CA and has a very low likelihood of compromise, you shouldn’t just assume that the key pair will not be attacked.
Creating a Strong Key for the Root Certification Authority
The Root CA certificate is easily generated during the creation of the CA. The Active Directory Certificate Services (AD CS) installation task within the Add Roles and Features Wizard prompts you for virtually everything. It even gives you an important warning right off the bat:
The name and domain settings of this computer cannot be changed after a certification authority (CA) has been installed. If you want to change the computer name, join a domain, or promote this server to a domain controller, complete these changes before installing the CA.
Once you’ve verified that the server is ready to become a CA and complete the wizard, you’re asked to make a few key decisions that are required to become a root CA. That’s because a root CA always generates a self-signed certificate. The data you must supply include the CA name, the Certificate Revocation List Distribution Point (CDP), and the parameters for the root CA’s key pair.
Your first option is to select whether the server should use an existing key pair or create a new one.
Figure 1. AD CS Configuration – Specify a new or existing private key.
Assuming you’re creating a new key pair, you’re presented with the aptly-named Cryptographic Options page.
Figure 2. AD CS Configuration – Specify the cryptographic options for the root CA key pair.
I call this an aptly-named page because it is, itself, cryptic. How do you make sense of this? It is really a confusing dialog, one that gives super-nerds a lot of flexibility but means little to most of us.
Selecting a Cryptographic Option for the Root Key Pair
To keep it simple: most people will want to keep the defaults on the first two options, which will generate a 2048-bit RSA key using Microsoft’s cryptographic library and storage methods. The default SHA1 hash algorithm is acceptable, but I would recommend SHA256 as it is likely to be the required hash algorithm and strength in the near future.
For the key length, I would go no higher than 4096 bits at this time. There is no benefit to a RSA key of 8192 or larger today unless you plan to issue a 1000-year certificate.
As for cryptographic providers, you can drop down the list and see a whole slew of them. Unless you have a specific compliance requirement, own a cryptographic appliance like a HSM, or use a specific smart card vendor with their own provider, there’s no benefit and the complexity of managing those keys may not be worth it.
If you want more Windows PKI articles please be sure to drop me a comment.