Like This Blog 2

Added by Mike Danseglio August 26, 2013

This is part 2 of selecting a Public Key Infrastructure (PKI) for your Windows Server 2012 environment.

In part 1; Selecting a Key Size for Your Root Certificate Server in Windows Server 2012 AD CS, we looked at creating a Strong Key for Root Certification Authority. In this post, we’ll look at deploying the Root CA.

Deploying 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 Provider for the Root Key Pair

The cryptographic provider is the software component that actually generates the key pair. It generally supports the standard Windows APIs and identifies which algorithms, key strengths, etc. The AD CS Configuration page queries CryptoAPI to determine which providers it should display in this list for you to choose.

Figure 3. AD CS Configuration – The list of cryptographic providers for generating the key pair.

In Windows Server 2012 the built-in cryptographic providers are:

• Microsoft Base Smart Card Crypto Provider
• Microsoft Enhanced Cryptographic Provider v1.0
• ECDSA_P256#Microsoft Smart Card Key Storage Provider
• ECDSA_P521#Microsoft Smart Card Key Storage Provider
• RSA#Microsoft Software Key Storage Provider
• Microsoft Base Cryptographic Provider v1.0
• ECDSA_P256#Microsoft Software Key Storage Provider
• ECDSA_P521#Microsoft Software Key Storage Provider
• Microsoft Strong Cryptographic Provider
• ECDSA_P384#Microsoft Software Key Storage Provider
• Microsoft Base DSS Cryptographic Provider
• RSA#Microsoft Smart Card Key Storage Provider
• DSA#Microsoft Software Key Storage Provider
• ECDSA_P384#Microsoft Smart Card Key Storage Provider

Some of these have obvious uses. For example, there are smart card providers that are used if you plan to store the private key on a smart card. If you deploy a cryptographic hardware device and have loaded the appropriate software, it will appear on this list as well. Some use the RSA algorithm, while others use elliptic curve cryptographic algorithms.

My advice: Unless you have a specific compliance requirement, use a hardware cryptographic appliance, 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. Stick with the tried-and-true RSA algorithm.

If you want more Windows PKI articles please be sure to drop me a comment.

Take care!
Mike Danseglio -CISSP / CEH
Interface Technical Training – Technical Director and Instructor