We have almost finished the configuration of the subordinate CA. In this post, I will present the post intsallation script used to set certain parameters, the PKI View tool that validates certain aspects of the configuration and also the ADCS Best Practices Analyzer.
Please note that there is still much to accomplish. We still have to configure the methods of certificate enrollment. How will clients request and obtain certificates? The web interface and Group Policy are two common methods, the latter interacting with the "autoenrollment" feature. We also have to address matters like high availability, backups and restores, as well as key archiving and recovery. I aim to examine at least some of these aspects in future blog posts.
***
Post-installation script for the subordinate CA
Here is the content of the script I used:
----
::Post-install script for Sub CA
::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz
::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 3
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod "Days"
::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"
::Apply the required AIA Extension URLs
certutil –setreg CA\CACertPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n
2:http://pki.machlinkit.biz/PKI/%%1_%%3%%4.crt\n
3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
::Apply the required CDP Extension URLs
certutil –setreg CA\CRLPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n
2:http://pki.machlinkit.biz/PKI/%%3%%8%%9.crl\n
11:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n
1:file://\\pki.machlinkit.biz\PKI\%%3%%8%%9.crl"
:: Enable discrete signatures in subordinate CA certificates
certutil -setreg CA\csp\AlternateSignatureAlgorithm 1
::Enable all auditing events for the Sub CA
certutil -setreg CA\AuditFilter 127
::Restart Certificate Services
net stop certsvc & net start certsvc
----
This script, similar to the script for the root CA, sets parameters such as the validity period of the base and delta CRLs, the overlap period, the validity period of issued certificates (certificates that the subordinate CA issues) and defines the AIA and CDP Urls, in other words the locations where certificates and CRLs can be found, respectively for certificate chaining and for verification of revocation lists.
I may not have yet explained the concept of "overlap". After the validity of a CRL expires, this is the period during which the CRL can still be used. Overlap is a sort of grace period that allows the PKI administrators extra time to resolve problems before the PKI stops functioning. The overlap period cannot exceed the validity period of the CRL. So if I have a CRL with a validity period of 3 days, I could not configure the overlap period for 4 days. On the other hand, 2 days would be an acceptable setting.
The Url parameters are similar to those for the root CA with one addition: the file Url for the CDP. This addition is necessary so the CRL is published automatically to the file share indicated. Otherwise, an administrator would have to copy the CRL file manually from the location on the C: drive to the file share.
Note: we cannot publish the CRL directly to a web server using the http Url.
Note: the character combination \n separates the different Urls. For readability, I clicked "Enter" after each \n. If you copy the text above as a model, you may have to backspace as needed to remove my "Enters". Of course, you will obviously adjust the domain name as appropriate, not to mention the Urls. For example, if you use delta CRLs, you will replace the 1 in the file Url with 65. Please see the references in Part 2 of this blog post series for more information:
PKI View
PKI View is a tool that validates the configuration of the AIA and CRL locations. In particular, it tells us if the certificates and revocation lists are accessible at the Urls indicated in the script shown above for the subordinate CA and the script used previously for the root CA.
PKI View can be found in Server Manager, under the Active Directory Certificate Services role icon:
This is PKI View (even though the name is not specfically stated). At the summit of the hierarchy, we have "Enterprise PKI". In the right pane, we see the next level down which is the root CA. We also see a yellow exclamation mark icon with the status "Warning".
What is wrong?
We can move down one level to see:
At the root CA level (in my network, that is "PKI-ROOT-CA"), we can see the status of the root CA certificate, the AIA locations for both HTTP and LDAP and also the CDP locations for HTTP and LDAP. The status of all of these elements is "OK". This simply means that the certificate is valid and that certificates and (certificate) revocation lists are accessible for consultation. Any application that wants to construct a certificate chain to the summit of our PKI, or consult the CRL, will be able to do this.
In fact, it looks like, at this level, the only warning icon concerns the subordinate issuing CA which in my network is called "Machlinkit Issuing CA". We have to move down one more level to see what is the matter:
At this level, we can see that the subordinate CA certificate is OK and that it is accessible both via HTTP and LDAP. The yellow warning icon indicates that the CRL status (at both the HTTP and LDAP locations) is "Expiring". In fact, this is normal. We had configured a 3 day validity period for the CRL (with a 2 day overlap) and PKI View simply warns us that the current CRL is about to expire. As long as the CA is able to publish a new CRL to the locations in question (which we would see once the CRL does expire - look at the time stamps), the PKI will still function.
Otherwise, all is well. PKI View can access the certificates and CRLs published to Active Directory (LDAP) and to our web server (HTTP). If we open the file share to which we are publishing the CRL, we should see something like this:
Both the subordinate CA certificate and the CRL published by the subordinate CA are present (as well as the corresponding files of the root CA).
What would the PKI View show if, for example, the CRL could not be located at one of the locations indicated in the certificate extensions?
I'll illustrate this by temporarily moving the subordinate CA's CRL to another location (that would be the Machlinkit Issuing CA(1).crl file in the screenshot above). We would see the red error icon with status "Unable to download":
Note: if you tested this, following my example, you can eliminate the error above by simply moving the .crl file back to its original location.
***
Active Directory Certificate Services - Best Practices Analyzer
The ADCS Best Practices Analyzer (BPA) is another tool that can validate the configuration of our PKI. Like PKI View, we access the tool in Server Manager (see below). We select the ADCS icon and then, in the right pane, scroll down until we reach the "Best Practices Analyzer" section. In the Action pane (far right), we click on "Scan This Role". The ADCS role is scanned and results are displayed as shown in the screenshot below (click to enlarge):
In my case, there are 3 warning entries. I have not configured autoenrollment in Group Policy and I have placed the CA database and log files on the system drive. Autoenrollment is not a necessity (we can request certificates manually and wait for administrative approval) but it does facilitate the delivery of certificates to large numbers of users and computers. In this case, we regulate access to certificates based on membership in specific security groups.
As for the location of the database and log files, I indicated, when I installed the ADCS role, that in production, we would not place these files on the system drive. In a test network, this does not matter and will not have any adverse effects.
***
So far, we have accomplished much (and validated our configuration with PKI View and the ADCS BPA) but much more remains before our PKI will be useful to our clients.
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 7: configuration of the subordinate CA (end) 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.