To finish this series, in this article we will configure DNS records and the website which will host AIA and CDP locations. In the end, we will have a fully operational Two Tier PKI Hierarchy in Windows Server 2016
You can retrieve the other articles of this series following these links:
You can obviously adapt theses steps to your environment and your needs as your configuration match to the AIA and CDP path options.
As explained at the beginning of this article, in this deployment we will use our subordinate CA to host the website serving AIA and CDP check requests. First, create the DNS alias based on an A record on our DNS pointing to our subordinate CA (AUTH01.lab.local).
Then create the associated website and the physical folder path.
You will need to give modification rights on your website root folder, subfolders and file to Cert Publishers AD group.
Once the configuration is done, simply copy your CRL file to CDP folder and the root CA to AIA folder. Then you can start certsrv service on the subordinate CA and check the configuration as below.
If you encounter some issue or want to have a more detailed view you can use the pkieview.msc console.
Finally, don’t forget to distribute the root CA certificate to your domain computers through GPO to validate the trust chain. Now you can use your two tier PKI to issue certificates and certificate policies in your domain!
I hope this article has been useful, don’t hesitate to ask questions in the comment section if you encounter some issues or if you need more information.
Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 2
Like for the root CA, you need to install Active Directory Certificate Services role.
This time, in addition of the Certification Authority role service, you can install other available role service depending on your needs. In this deployment, we will only install the Certification Authority Web Enrollment role service to give end-users the possibility to request some certificates based on certificate templates from the web console.
Once the role services are successfully installed, you need to configure them.
As explained at the beginning of the article, this server will act as an Enterprise Subordinate CA. It must be a domain member and online to issue certificates or certificate policies.
As we don’t have yet a private key, we will create a new one based on standard security best practices. If you need more information about the hash algorithm and key length choice, you can have a look at the first part of my previous article here.
Then we require a certificate from the root CA to allow this subordinate CA to issue certificates. And since the root CA is not a domain member and not online, we can’t use the first option. We will need to save the request to a file and copy it on the root CA.
As you can see, we have a warning that recalls us to use the request generated by this wizard to obtain the corresponding certificate from the root CA.
To submit the request generated by the subordinate CA to the root CA, just copy the file you can see above and submit a new request in the certsrv console of root CA.
It will create a pending request that you will need to manually approve.
Once the certificate is issued, you will need to export it as a file. You can either export it as .CER or .P7B format.
Then, go back to your subordinate CA and before importing the generated certificate, you will need to import the root CA certificate (the first certificate of your hierarchy) into the Trusted Root Certificate Authorities computer store. If you don’t do this action, when you will try to import the certificate previously generated, the certificate chain will not be trusted as the parent certificate will be unknown.
If you followed previous steps, the root CA certificate should already have been copied to your subordinate server with the CRL file and the freshly created subordinate certificate.
At this point, if you try to install your subordinate CA certificate, you will get an error as you can see below because your server will not be able to verify the certificate chain as the revocation list is not available.
But if your remember we already configured on the root CA the path to reach AIA and CDP through a website based on an alias. We will finish the deployment of this hierarchy in part 3.
Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 1
If you are new to the enterprise PKI concepts, let me give you some vocabulary and best practices. In Windows Server using AD CS role, your PKI can have several forms using the different component based on your needs.
Root Certification Authority (CA), is the root instance of the PKI trust chain. The first AD CS instance you install will need to be the root CA because this establishes the trust hierarchy.
Subordinate CA, is the child node in the PKI trust chain. A subordinate CA is one level under the root CA, or can be nested several levels deep under other higher level subordinate CAs.
Issuing CA, is/are subordinate CA that issue end-user certificates, however not all subordinate CAs need to be issuing CA.
Standalone CA, is an instance of AD CS service that is running on a non-domain joined server and does not integrate with AD.
Enterprise CA, is an instance of AD CS service that is running on a domain-joined server and integrates with AD.
You will also need to understand two components of a root CA, that are the Certificate Revocation List (CRL) that is part of Certification Revocation List Distribution Point (CDP), and the Authority Information Access (AIA).
CRL, is the list of all revoked certificate in the PKI hierarchy that is hosted by one or more CDPs.
AIA, define locations from which users can obtain the certificate for the root CA.
These files are hosted most of the time on an internal/public shared URL that can be accessed by anyone using a certificate from the root CA.
Best practices are something that will vary depending on your security needs, but in any case on of the main recommendation is that the root CA should be standalone, and offline most of the time. Because if anything happens to the root CA, the entire trust hierarchy is compromised, and it is much easier to revoke an issuing CA certificate and setup a new one than replacing the entire PKI infrastructure. But offline root CA will still be needed when the followings events occur:
Issuing CA certificate is expiring and needs to be renewed
Issuing CA certificate needs to be re-issued in order to change crypto parameters, such as the hashing algorithm. For example, if you need to migrate your CA to SHA-2 (see my article).
Issuing CA is compromised and needs to be revoked
A new issuing CA needs to join the trust hierarchy one level under the root CA.
The root CA certificate is about to expire and needs to be renewed
The root CA CRL is about to expire and needs to be regenerated.
For this deployment, we will use this infrastructure.
It is composed of an AD DS root domain (lab.local) based on two domain controllers (AD01.lab.local and AD02.lab.local), one offline standalone root CA, and an enterprise issuing CA (AUTH01.lab.local). Note that your standalone root CA does not even need to be connected to a network, in this case, you will need to use another way to transfer files during deployment.
In this first part, we will see how to deploy the Standalone Root CA. After installing your Windows Server 2016 (do not join the server to your domain), you will need to install AD CS role and configure your standalone root CA.
At this time you have a functional standalone root CA, but you will need to do some post-configuration. First even, if you put a validity period of 20 years during the configuration you will need to hard code it in the registry. You will need to modify the registry value of ValidityPeriodUnits in the registry key:
Then as this standalone root CA is not part of the domain and will be put offline, we will need to publish the CRL and AIA files to a custom URL hosted by another server (in this casa AUTH01.lab.local). In order to accomplish this, we need to run these two commands that will add registry keys, and restart certsvc service.
Now we can configure our custom location for CDP and AIA. For this, we will use an alias that will redirect to a website hosted by our enterprise issuing CA.
In this case, we will publish both CRL and AIA files to a website based on alias pki.lab.local. The advantage of using an alias is the possibility to move this website between web servers and even implement NLB for high availability.
To apply the changes we will need to restart again certsvc service.
Finally, we need to increase the CRL publication interval value because the root CA will be put offline and will not be able to generate a new CRL file each week. Actually, the CRL file will need to be regenerated if we implement a new CDP or another major change. In this case, we will just need to start the server hosting the root CA, implement the configuration and regenerate a new CRL to copy on issuing CAs.
After the CRL generation, you can retrieve both CRL and AIA files on C:\Windows\System32\CertSrv\CertEnroll. You will need to copy these files for a later use a network share if your server is connected to a network or on USB drive if it is a physical server and not connected to a network.
In part 2, we will see how to deploy the second component which is the Enterprise Subordinate Issuing CA.
Migrate Microsoft Certification Authority to SHA-2 Algorithm
Microsoft is announcing a policy change to the Microsoft Root Certificate Program. The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016. Using the SHA-1 hashing algorithm in digital certificates could allow an attacker to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.
Microsoft recommends that certificate authorities no longer sign newly generated certificates using the SHA-1 hashing algorithm and begin migrating to SHA-2. Microsoft also recommends that customers replace their SHA-1 certificates with SHA-2 certificates at the earliest opportunity.
But remember, before planning this migration you will have to test every application within your environment to make sure that they will be able to do certificate chaining and revocation checking against certificates and CRLs that have been signed using the SHA2 algorithms. Moreover, Windows Server 2003 and Windows XP clients cannot obtain certificates from a Certification Authority if its configured to use SHA-2 256 or higher encryption until you apply this hotfix.
Once planning phase is completed, you need to follow these steps to migrate your CA from SHA1 to SHA2. First, you can confirm that your CA is currently using SHA-1 by opening Certification Authority MMC and looking at properties of your root certificate.
It’s always a good idea to backup your CA database and registry keys before migrating your encryption algorithm.
When your CA is fully backup, you can move to the migration step. To change hash algorithm version you just need to run a PowerShell command and restart CA service.
Your Certification Authority is now issuing certificate using SHA256, but your current certificate is still as SHA-1 hash algorithm. So you have to renew CA certificate and generate a new signing key.
Now you can confirm that your root certificate is using SHA256 looking at detail.
Then, you need to verify that the certificate revocation list publishes and has the correct signature algorithm and signature hash algorithm. First, publish the certificate revocation list (CRL) by running the following command.
Then, go to %windir%\system32\CertSrv\CertEnroll and locate the CRL files. Normally you should see this kind of display for each CRL files.