Suite B Public Key Infrastructure Part I
I hope everyone out there is gearing up for an excellent week! Now then, the first order of business here on the blog is to get going on a quick post about commissioning a Server 2012 R2 offline root certificate authority in accordance with RFC 5759 (NSA Suite B cryptography). Folks that operate in the government and federal space may have specific cryptography requirements for end entity (leaf) certificates, and the CA or CAs that issue these certificates and therefore may need to adhere to RFC 5759. Take careful consideration when deploying a Suite B capable PKI, you may want to stand up this PKI side-by-side with your existing PKI for a couple of reasons (for starters of course):
- Requirements for both ECC and non-ECC certificates
- Third party application and service compatibility
- Different certificate policies (cp/cps)
- Different hardware requirements (Hardware Security Modules?)
- etc.
As several topics on Public Key Infrastructure (PKI) have been covered in depth, I won’t cover design considerations of a PKI, but instead I’ll show a few things to keep in mind to make sure you’re working towards compliancy with the requirements in RFC 5759 if that's your goal. The lifetime of a typical PKI can surpass turnover of a given system administrator or team, so for a production environment it's a good idea to leverage someone who is experienced in these things. Speaking of experience...before we get into it I’d like to give a special thanks to one of our support escalation engineers Brad Held for helping out here on some of the information! Thanks Brad!
For this exercise we’ll be using the following configuration settings for an offline root CA. Note that the RFC states that either curve P-256 or curve P-384 may be used. Here we’ll use the P-384 curve. Be sure to check 3rd party compatibility with these algorithms as not all vendors support them.
CSP: ECDSA_P384#Microsoft Software Key Storage Provider
Key Length: 384
Hash Algorithm: SHA-384
A couple of things to be aware of here, for self-signed CA certificates (Root CAs) the RFC states that the following extensions must be present: subjectKeyIdentifier (SKI), keyUsage, and basicConstraints. Furthermore it states that the keyUsage extension must be marked as critical, and that the keyCertSign and CRLSign bits must be set. All other bits (except for digital signature and non-repudiation, which may be set) must not be set. Great Scott, thats a mouthful!
First on the punch list is to mark the Key Usage extension as critical on the root CA certificate. In order to do that we need to configure some settings in the CAPolicy.inf file that is parsed and used during the CA installation. There are quite a few great articles out there on the CAPolicy.inf syntax. The CAPolicy.inf file needs to be placed in the %windir% directory in order for the installation routine to read it in and use the settings:
Here’s where the rubber meets the road for marking the key usage extension as critical. We need to add the highlighted areas below to the CAPolicy.inf file to mark the key usage extension as critical:
So let me shed a little light on the entries above. Under the [Extensions] section 2.5.29.15 is the object identifier (OID) for keyUsage, and the other line well…marks it as critical. Score! The key usage is represented as a bit string and more information on how to interpret the key usage can be found in KB88810. Essentially the first, second, and third bytes are fixed (03 02 and 01 below). It appears the CRL_SIGN and OFFLINE_CRL_SIGN bits are one and the same (based on the output). AwIBhg== is the base64 encoded version of the 03 02 01 86 bit string. The highlighted hex values are added which gives the value of 86:
AwIBhg== decodes to 03 02 01 86
#define CERT_DIGITAL_SIGNATURE_KEY_USAGE 0x80
#define CERT_KEY_CERT_SIGN_KEY_USAGE 0x04
#define CERT_OFFLINE_CRL_SIGN_KEY_USAGE 0x02
#define CERT_CRL_SIGN_KEY_USAGE 0x02
OK now that we have the correct entries in the CAPolicy.inf file (you placed it in %windir% right?) we can begin the offline root CA installation. Hopefully you’re logged in as an admin; if so fire up server manager, and let’s add some roles and features:
We want to select AD CS which is highlighted below:
We’ll need to add the required features:
Here we don’t need to select anything additional so let’s move on to the next screen.
Take note of the items here, all standard stuff.
For this exercise we only want the Certification Authority role service:
And finally we can install the AD CS bits!
Once the bits are finished being laid down on the box we’ll want to configure AD CS, so we’ll click the highlighted area:
Hopefully you’re logged on as an administrator so here we can just click Next.
Select the CA role service to configure.
Select standalone CA, and click Next.
Select Root CA, and click Next.
Here we’ll create a new private key:
This brings us to cryptography…where we need to do some stuff to meet some of the RFC requirements. Remember this time we’re going to use the ECDSA curve P-384 and the CSP we’re going to use is the ECDSA_P384#Microsoft Software Key Storage Provider. RFC 5759 also states that the CA must have an ECDSA signing key, in addition any certificate and crl must be hashed using SHA-256 or SHA-384, and be matched to the size of the signing CAs key. That being said we will use the following csp and hash algorithm. Let’s fill it out and go…Next.
Here you can set the common name of the CA, and optionally a distinguished name suffix. For this exercise I’ll leave the suffix out. Next!
Here I’ll set this guy for a certificate lifetime of 20 years and…Next.
I’ll leave the defaults for this VM for database and logs location.
This brings us to the confirmation page; here we can review the configuration before we configure the CA. So let’s spin her up and see what we get. Configure!
Hopefully you arrive here…Finish!
Verification
We’ve set the CAPolicy.inf settings to mark the key usage extension as critical. So we need to go about our ways to verify in fact that it is marked as critical. This will not show in the UI when you examine the certificate so we turn to the ever handy certutil command to do just that. Here is a great reference on certutil:
Navigate to the %windir%\System32\CertSrv\CertEnroll directory and issue the following command:
certutil –v “name of your CA certificate.crt”
Examine the output and navigate to the “Certificate Extensions” section. Here you’ll want to find two particular extensions, Key Usage and BasicConstraints – both of which must be marked as critical according to the RFC. You should see the following highlighted for both of these extensions:
2.5.29.15: Flags = 1(Critical)
RFC 5759 also states that the path length constraint must not be present. You can see the SKI and the other RFC specific things highlighted in yellow below. Take note of the path length constraint under the BasicConstraints extension in the certutil output, it is set to None; which in MSFT speak means it isn’t there : )
Obviously this CA is far from finished, there are a lot of other things you'd want to do to this CA according to your certificate policy and/or certificate practice statement, like configure authority information access (AIA) and crl distribution point (CDP) extensions, CRL lifetime, etc.. these topics have also been covered in depth on TechNet. Another good article that's worth the read is the Suite B PKI Step-by-Step Guide so definitely check it out, there are some certutil commands documented there that you may want to run on your suite B CA(s) if you have specific cryptography requirements for key archival, etc.. Well that about wraps it up for this post folks. I hope you find it useful in your testing of suite B PKI services and applications. I also hope it clears up any confusion about getting some of these requirements met. Should be back soon with another post on issuing certificates (sub-ca and leaf flavors) from this type of CA in accordance with the RFC.
See you next time!
Jesse Esquivel