Microsoft Certificate Authorities – Avoiding re-work

posted in Best Practices, How to on by

This is definitely not a beginners guide to certificates, what they are, or how they work.  This guide is designed for anyone tasked with building a CA infrastructure and wants to avoid all of the the pitfalls (and re-work) upfront.

The majority of CA builds take so long, because of the dependency chain that gets longer and longer the further down the road you get with the build.  Of course, often, by the time you get to the end and realise you’ve made a mistake, you need to invariably go right back to the beginning and rebuild *everything* from scratch.  Not ideal.

 

Let’s assume you’re going to follow at least some of the Microsoft Best practices and build a 2-tier solution with an offline Root CA, and a single online Enterprise (issuing) CA.  Of course, no one tells you until it’s too late that you actually need a third server in the mix – a distribution point for your Certificate Revocation Lists (CRLs), known as a CDP (CRL Distribution Point). You also need an Authority Access Information (AIA) distribution point – which is a fancy way of saying “location of the Root CA public-key certificate” – and can be easily bundled into your CDP server (which need not be dedicated to the CA infrastructure either).

And although you could, it’s generally not a good idea to have your CRLs live on the Enterprise CA server, so a separate IIS server is in order.

A “minimum” architecture should then look like this:

 

This guide also assumes you’re going to use a Key Recovery Agent, in the event that you need to recover lost/broken private keys.

At a very high-level, you should complete these steps, in this order.

Active Directory

  • Create AD groups for each type of certificate you want to issue.  EG: Member Servers, BitLocker etc.
  • Add Enterprise CA computer object into group named Cert Publishers
  • Create a service account named svc_kra (or whatever your naming convention allows for)

 

Configure CRL Server

This can be an existing shared server, or dedicated.

  • Install IIS
  • Create a folder called “pki” (somewhere obvious, like c:\pki), set NTFS permissions for Change to the Cert Publishers group
  • Create 3 folders under c:\pki named AIA, CDP and CPS
  • Share the pki folder and allow Everyone, Full Control share permissions
  • Create a virtual directory in IIS for each of the folders AIA, CDP and CPS (named the same)
  • Enable Directory Browsing on each virtual directory
  • Configure Double Escaping for each virtual folder in IIS (google this)
  • Create a CNAME record in your DNS named “pki” and point it towards this IIS server
  • Create a CPS.txt file and place it in the CPS folder (maybe fill this in with your Certification Practice Statement)
  • Test HTTP browsing to the server and it’s virtual directories

 

Root Certificate Authority

  • Assumptions:
    • Root CA certificate will be valid for 10 years
    • Root CA must re-publish its CRL every 2 years
    • Enterprise CA certificate will be valid for 5 years
  • Create a file in c:\Windows called CAPolicy.inf, enter this (modify as required) and save:

  • Install Microsoft Certificate Authority Role and configure as Standalone Root, with key of 4096 bits, and validity period matching the CAPolicy.inf file setting.
  • Run these commands to set certificate and CRL defaults:

  • Confirm the Above in the registry, here: HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<ca name>
  • On the properties of the Root CA, remove all CDP settings
    • Create one CDP location as http://pki.yourdomainname.com/CDP/<ServerDNSName>_<CaName><CertificateName>.crl which should be included in CRLs (there’s a checkbox)
    • Create a second CDP location at c:\windows\system32\CertSrv\certEnroll\<ServerDNSName>_<CaName><CertificateName>.crl and set that to be the Publish To location (there’s a checkbox)
  • On the properties of the Root CA, remove all AIA settings.
    • Create one AIA location as http://pki.yourdomainname.com/AIA/<ServerDNSName>_<CaName><CertificateName>.crt
  • Publish the CRL with certutil.exe -CRL
  • Copy the .crl file from c:\windows\system32\CertSrv\CertEnroll\ into the CDP folder on the CRL server
  • Copy the .crt file from c:\windows\system32\CertSrv\CertEnroll\ into the AIA folder on the CRL server
  • Copy the .crt file from c:\windows\system32\CertSrv\CertEnroll\ to a Domain Controller and create a GPO that publishes this certificate to the Trusted Root Certifications Authorities store on every computer.

 

Enterprise CA

  • Assumptions:
    • The Enterprise CA issued certificates will have a maximum validity of 12 months.

 

  • Install the Certificate Authory role on the server, configuring it as an Enterprise Subordinate with a new certificate key length of 4096 bits and 5 year validity. Save the subordinate certificate request to a file.
  • Take the certificate request to the Root CA and submit/approve the request.
  • Export the approved certificate (open the certificate, Copy To File)
  • On the Enterprise CA, in the Certification Authority snap-in, select to Install Certificate (with the exported certificate from the Root CA)
  • Confirm the completed certificate (with private key) is in the Enterprise Root CA servers Personal certificate store
  • On the properties of the Enterprise CA (in the Certification Authority snap-in), remove all CDP settings
    • Create one CDP location as http://pki.yourdomainname.com/CDP/<ServerDNSName>_<CaName><CertificateName>.crl which should be included in CRLs (there’s a checkbox)
    • Create a second CDP location at c:\windows\system32\CertSrv\certEnroll\<ServerDNSName>_<CaName><CertificateName>.crl and set that to be the Publish To location (there’s a checkbox)
    • Create a third CDP location at \\pki.yourdomainname.com\pki\CDP\<ServerDNSName>_<CaName><CertificateName>.crl and set that to be the Publish To location (there’s a checkbox)
  • On the properties of the Enterprise CA, remove all AIA settings.
    • Create one AIA location as http://pki.yourdomainname.com/AIA/<ServerDNSName>_<CaName><CertificateName>.crt
  • Run these commands to set certificate and CRL defaults:

  • Confirm the Above in the registry, here: HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<ca name>
  • Restart Certificate Services
  • Publish the CRL with certutil.exe -CRL
  • Confirm new CRL file is located on CRL server in the CDP folder.
  • Add the svc_kra account into the Local Admins group on the Enterprise CA server (this can be removed after key recovery is configured)

 

  • Install Bitlocker Drive Encryption from Server Manager (if not already instaleld).  Needed if you want to recovery Bitlocker keys.
  • Duplicate the Key Recovery Agent to the new Certificate Template and name it appropriately. Configure with:
    • 4096 bit key
    • Add the BitLocker Application Policy Extensions (there’s two of them)
    • Set the permissions for the svc_kra service account to Read and Enroll for this certificate template
  • Issue the new template to the Certification Authority
  • Logon as the svc_kra user to the Enterprise CA server and request a new certificate (the Key Recovery template you just created should be the only one available).  You’ll need to manually approve this request.
  • From the command-line run “certutil retrieve <requestID> c:\temp\svc_kra.cer”  (replace <requestID> with request ID from Certificate Authority snap-in)
  • Import the .cer file into the Personal certificate store for the user.
  • Export the certificate with private key included and store securely.
  • Export the certificate WITHOUT the private key and keep hand (to be used later)
  • Remove the certificate from the Personal certificate store
  • Log off as the svc_kra user account, and log back on as an Administrator.  Remove the svc_kra account as a local Administrator.
  • In the properties of the Enterprise CA, enable “Archive the key” and select the number of recovery agents to 1.  You might want to have more than one, just in case, but we’ll proceed with just one.  Add the previously exported certificate (without the prive key) of the svc_kra user.

 

Enterprise CA – Other Templates 

You should probably configure other templates for use; perhaps a Domain Controller template or a general member Server template. Some important things to remember when creating new templates:

  • Remove the Domain Computer permissions and add Enroll and AutoEnroll to a security group – like the ones created earlier.
  • Always tick the box on the Request handling tab to “Archive the subject’s encryption key.  Think carefully about the option to “Allow private key to be exported”.
  • Use 4096 bit keys
  • Configure the Subject Name to come from the DNS name

 

Active Directory

  • Create a GPO to enable Auto-enrollment for all computers/servers/users (Windows Settings > Security Settings >Public Key Policies) and link it to the root of Active Directory. Users/computers will have auto-enroll enabeld, but can only enroll for certificates based on the permissions set in the certificate template (why we needed those AD groups earlier.
  • Create a GPO with KRA public key certificate linked to the OU containing Bitlocker protected computers.
    • Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Bitlocker Drive Encryption > Add data Recovery Agent.

 

Root CA

  • After the Enterprise CA has its certificate you can shut down the Root CA – keeping in mind when it needs to be brought back online to republish its CRL or re-issue the cert for the Enterprise CA server.

Leave a Reply

Your email address will not be published. Required fields are marked *