To continue this series, in this article we will continue the deployment of our Two Tier PKI Hierarchy in Windows Server 2016 by deploying the Enterprise Subordinate Issuing CA.
You can retrieve the other articles of this series following these links:
- Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 1
- Installing a Two Tier PKI Hierarchy in Windows Server 2016 – Part 3
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.