How can I configure PKI in a lab on Windows Server 2016 – Part 2

In part 1 of this series, you configured your LAB for a 2 tier PKI hierarchy running on Windows Server 2016. You used PowerShell to create some virtual machines, and then installed Windows Server 2016,  Windows 10 Enterprise version 1803 and optionally Smoothwall 3.1 before configuring the IP address scheme and Computer Names on the virtual machines. Finally you configured ADDS on DC01 so that you have a working Domain Controller for the rest of this LAB.

In this part you’ll install and do initial configuration on the Standalone Offline Root CA.

What is a Standalone Offline Root CA ?

If you’ve never dealt with PKI before you are probably wondering what a Standalone Offline Root CA is and why do you need it. I’ll quote the following paragraph from the excellently written article about a Standalone Offline Root CA here. If you don’t read the article itself, at least read the Quote below.


A root certification authority (CA) is the top of a public key infrastructure (PKI) and generates a self-signed certificate. This means that the root CA is validating itself (self-validating). This root CA could then have subordinate CAs that effectively trust it. The subordinate CAs receive a certificate signed by the root CA, so the subordinate CAs can issue certificates that are validated by the root CA. This establishes a CA hierarchy and trust path.

CA Compromise

If a root CA is in some way compromised (broken into, hacked, stolen, or accessed by an unauthorized or malicious person), then all of the certificates that were issued by that CA are also compromised. Since certificates are used for data protection, identification, and authorization, the compromise of a CA could compromise the security of an entire organizational network. For that reason, many organizations that run internal PKIs install their root CA offline. That is, the CA is never connected to the company network, which makes the root CA an offline root CA. Make sure that you keep all CAs in secure areas with limited access.

To ensure the reliability of your CA infrastructure, specify that any root and non-issuing intermediate CAs must be offline. A non-issuing CA is one that is not expected to provide certificates to client computers, network devices, and so on. This minimizes the risk of the CA private keys becoming compromised, which would in turn compromise all the certificates that were issued by the CA (1).

To cut a long story short, you should use a Standalone Offline Root CA because it lowers the possibility of compromise and ensures reliability of your Certificate Authority infrastructure.

Step 1. Create a CAPolicy.inf file

Before installing the Standalone Offline Root CA, you should create a CAPolicy.inf to define ‘default’ settings for CA templates, some of these settings cannot be changed later and you want them in place before creating any certificates on the Standalone Offline Root CA.


The CAPolicy.inf is a configuration file that defines the extensions, constraints, and other configuration settings that are applied to a root CA certificate and all certificates issued by the root CA. The CAPolicy.inf file must be installed on a host server before the setup routine for the root CA begins. When the security restrictions on a root CA are to be modified, the root certificate must be renewed and an updated CAPolicy.inf file must be installed on the server before the renewal process begins (2).

So now that you know that you should create the file as a first step, let’s go and do that. On the #11_RootCA virtual machine (RootCA), login as Administrator using the password specified.

Open an administrative command prompt and type the following:

notepad C:\Windows\CAPolicy.inf

and press ENTER, when prompted to create new file, click Yes. Paste in the following text into the new CAPolicy.inf file.

Signature="$Windows NT$"


Once done, save the file.

Note: Any misspellings or mistakes will be ignored, so please copy/paste carefully. To understand what these values are, and why you are using them please see the following link, but in a nutshell, you are telling the CA that by default the Root CA should issue certificates that are valid for 20 years, feel free to adjust accordingly if you think it’s appropriate but be aware of the consequences (having to re-issue certificates etc.).

Continue reading this guide @ here.

This entry was posted in PKI. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.