In this series, we will see how to deploy a two tier PKI hierarchy in Windows Server 2016:
- Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 2
- Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 3
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.
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.