In my previous post, we created a capolicy.inf file, placed it in the %windir% and then installed the Active Directory Certificate Services role, configuring our first server as the organization's "root CA" (certificate authority).
We will now finish the configuration by running a script that defines certain settings, in particular those for CRL Distribution Points (CDP) and Authority Information Access (AIA):
--------------------------------------------------------------------
::Post-install script for Root CA
::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz
::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"
::Apply the required AIA Extension URLs
certutil –setreg CA\CACertPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n
2:http://pki.machlinkit.biz/PKI/%%1_%%3%%4.crt"
::Apply the required CDP Extension URLs
certutil –setreg CA\CRLPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n
2:http://pki.machlinkit.biz/PKI/ %%3%%8%%9.crl"
:: Enable discrete signatures in subordinate CA certificates
certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1
::Enable all auditing events for the MachLinkIt Root CA
certutil -setreg CA\AuditFilter 127
::Restart Certificate Services
net stop certsvc & net start certsvc
First, two remarks:
The "CDP" is the "CRL Distribution Point". This is a section (or "extension") in the certificate's properties that (in the form of URLs) indicates where the certificate revocation lists are published. Common options include Active Directory or a web site. Remember that this list must be consulted so revoked certificates cannot be used to grant access to resources.
The "AIA" (Authority Information Access) section of the certificate properties indicates where the issuing CA's certificates are published. Applications consult these URLs when building what is known as a "certificate chain". In practice, the application will verify not only the certificate presented by the end-user (or computer) but also the certificate of the CA that issued the end-user certificate.
Note: of course, the reader will adjust the domain and organization names as appropriate. Using "machlinkit" will not produce good results in your network!
Now let's take a look at each section of the script:
certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz
This line defines the name of the Active Directory configuration partition. It is essential. I omitted it once when first learning about PKI and such an omission will prevent proper PKI operations.
-
certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
These lines define the CRL publication interval. At the end of the period defined, it is expected that a new CRL be published. The Delta CRL is optional and I have opted not to use one.
-
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"
This section defines the validity period for issued certificates (and NOT the validity period of the root certificate which was configured earlier during ADCS installation). In essence, it means certificates issued to the subordinate CAs will be valid for 10 years.
-
CDP and AIA sections (please see script above)
These two sections are by far the most complex. A detailed description of all the options is beyond the scope of a simple blog post, so I will refer the reader to the sources indicated in the first blog post of this series.
I will say that the resulting settings are appropriate for a root CA.
These settings correspond to those in the "Extensions" tab of the root CA properties. We can view them in the Certificate Authority console. Enter "certsrv.msc" in the search box (Start | Search Programs and Files).
For AIA, nothing is configured for the local C: drive. Even with online subordinate CAs, this location cannot be accessed by applications seeking to construct a certificate chain. This is obviously true for an offline CA as well.
On the other hand, we will want to indicate a URL so certificates can be stored (and consulted) in Active Directory and on a web server (next two screenshots):
For the CDP, we will publish the root CRL to the location below:
And here are the CDP settings for LDAP and HTTP:
Yes, as the screenshots above suggest, this all can be configured manually. The script has the advantage of allowing us to (re)apply a consistent group of settings.
As for the final sections, we enable discrete signatures, auditing (both optional) and then restart Certificate Services so the settings take effect.
***
True, what we have just presented above appears complex and can be confusing. Some readers may have questions. For example:
"We published a CRL to a location on the C: drive of the offline root CA. Since it is offline, how can this CRL be accessed?"
"We've configured the CA with indications (URLs) that designate the locations at which its certificate can be consulted. Once again, how is this possible if the root CA is offline?"
These questions form an excellent transition to our next steps.
Since the root CA is offline, we must copy both...
- the certificate of the root CA (and)
- the CRL of the root CA
and publish them manually at the locations indicated above:
- in Active Directory
- on the website designated by the HTTP URL. This website can be hosted on the subordinate CA itself - or elsewhere.
The certificate of the root CA as well as its CRL can be found here:
C:\Windows\System32\certsrv\certenroll
We can copy these two files to a flash drive or burn them to a CD/DVD and then place them in the locations indicated above on the subordinate CA.
Once we complete the installation of this subordinate CA, those operations will be the subject of my next blog post.
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 4: configuration of the root CA (continued) on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.