Installing a Two Tier PKI Hierarchy in Windows Server 2012: Part VI, Post Configuration of an Enterprise Subordinate Certification Authority
In the last episode of this blog series I installed an Enterprise Subordinate CA. In this episode I am going to perform post configuration of this CA.
So, let’s first sum up where I am with my setup. I have installed my Root and Subordinate CA. I have configured the Root CA. I am using LDAP (Active Directory) and HTTP Repositories to host the CA Certificates and CRLs. From a best practices standpoint the one major issue I have with this setup is I am using the Issuing CA to host the HTTP AIA and CDP Repositories. This is a problem, because it means I have a single point of failure for the HTTP AIA and CDP Repositories. I will be addressing how to fix this in a future blog posting. However, the one good thing I have going for me in terms of the HTTP repositories is that I chose a DNS Name (pki.fourthcoffee.com) that is not a machine name. This configuration allows me to later move the HTTP Repositories without having to reconfigure the AIA and CDP extensions in any of my certificates.
The steps I am going to perform in this blog post are:
- Run post-configuration script to configure the CA
- Configuring the DNS Alias for the HTTP repository
- Publish Root CA Certificate and CRL to HTTP Repository
Post-Configuration Script
The 1st line in my configuration script is the following:
certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2: https://pki.fourthcoffee.com/certenroll/%%3%%8%%9.crl\\n3:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
This line configures where the CRL is published and what is defined in the CDP extension of issued certificates. If you are interested in better understanding the Variables and Numbers used in this line you can reference a blog I wrote a couple of years back: https://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx
The 2nd line in my configuration script is the following:
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2: https://pki.fourthcoffee.com/certenroll/%%1\_%%3%%4.crt\\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
This line configures where the CA Certificate is published and what is defined in the AIA extension of issued certificates. If you are interested in better understanding the Variables and Numbers used in this line you can reference a blog I wrote a couple of years back: https://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx
Lines 3-7 of my configurations script are:
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 3
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
These lines Configure a CRL Period of 3 Days and a CRL Overlap Period of 3 Days. Delta CRLs are disabled. These lines will effectively configure a CRL that is valid for 6 days, and configure the CA to publish a new CRL every 3 days. For additional information, please see a recent blog post on this subject: https://blogs.technet.com/b/xdot509/archive/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies.aspx
Lines 8-9 of the script are:
certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod "Years"
These two registry keys combine to set the longest maximum validity that a CA can issue a certificate for. In other words with this setting configured as 5 Years, my CA can issue certificates that are valid for up to 5 years. The default for an Enterprise CA is 2 Years. This does not mean, however, that all certs I issue will be valid for up to 2 years. First, the CA cannot issue certificates that are valid for longer than it’s own certificate. So, if I were to forget to renew my CA certificate, I would eventually reach a point in time when it would not be capable of issuing a 5 year certificate. So, the CAs lifetime is one constraint. However, how long you actually issue certificates is set configured on a Certificate Template, and on a Certificate Template basis. In other words I could configure some templates to allow issuance of 1 year certificates, some for 2 year certificates, some for 5 year certificates, and so on.
Line 9 of my configuration script is the following:
certutil -setreg CA\AuditFilter 127
This line enables auditing on the CA itself. In order for Auditing to be completely enabled, Auditing for Object Access, Success and Failure must be enabled in the Security Policy as well. I will cover securing the CA in an upcoming blog post.
Line 10 is:
net stop certsvc & net start certsvc
This line restarts the CA service (Active Directory Certificate Services). The restart is needed for the CA to pickup the configuration changes that I made in the previous lines.
Line 11 of the script is:
certutil –CRL
This line publishes a new CRL, this is necessary because I have altered the CRL Publishing intervals.
Running the Post-Configuration Script
Now that we have discussed the configuration script, I need to run the following script as Administrator.
certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2: https://pki.fourthcoffee.com/certenroll/%%3%%8%%9.crl\\n3:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2: https://pki.fourthcoffee.com/certenroll/%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriodUnits 3
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod "Years"
certutil -setreg CA\AuditFilter 127
net stop certsvc & net start certsvc
certutil –CRL
Configuring the DNS Alias for the HTTP repository
The HTTP repository I am using for the AIA and CDP repositories is: https://pki.fourthcoffee.com. So, I need to either create an A record that points to my CA with this name or create a CNAME record for this name that aliases the CA. I need to point it the DNS record to my CA, since my CA is hosting the AIA and CDP repositories. For simplicities sake, I am including instructions for creating a CNAME below:
Open DNS Manager (dnsmgmt.msc), navigate to the appropriate DNS zone, right click and select New Alias (CNAME…) from the context menu.
Type in the name of the Alias (in my case this is “pki”). Then click Browse…
Select the name of the machine you are aliasing, in my case this is FCCA01, which is hosting the AIA and CDP repositories, and click OK. Then click OK again.
Publish Root CA Certificate and CRL to HTTP Repository
Previously I copied the Root CA Certificate and CRL off of the Root CA so that I could publish them to AD. Since I am hosting the AIA and CDP repositories from the \CertEnroll directory on the CA, I now need to copy these two files to C:\Windows\System32\CertSrv\CertEnroll\ directory on my Issuing CA, since it is hosting the AIA and CDP repositories.
Health Check
Finally, I run PKIView.msc to spot check the health of my PKI. Everything comes back OK.
Conclusion
In this blog posting I performed post-configuration of the CA, which included:
- Run post-configuration script to configure the CA
- Configuring the DNS Alias for the HTTP repository
- Publish Root CA Certificate and CRL to HTTP Repository
So, what am I missing at this point. Well, I am missing a couple of configuration steps. The first is securing the Web Enrollment website with SSL. The second is locking down the CA from a security perspective. I will be covering these steps in upcoming blog posts.