In this blog post, I will configure my root CA.
As mentioned in previous blog posts, the root CA is offline for security reasons (it is very difficult to "hack" an offline server to which one has no physical access). Any certificates or certificate revocation lists will have to be saved to media (USB key, CD/DVD) and transferred to the subbordinate CAs manually. We will do this later.
In my test network, based on VMware workstation virtual machines, I will simulate this by creating the root CA server with no NIC:
We must start with the root CA and then create the subordinate CAs
Note: remember that just as end-users receive a certificate from a subordinate CA, the subordinate CAs receive a certificate from the root CA. But who issues the certificate for the root CA? The root CA. Yes, that's right. The certificate for the root CA is "self-signed".
I will name the root CA "PKI-Root-CA". That will suffice for my practice network.
Since it has no NIC, there are no TCP/IP settings to configure.
Likewise, it will be a stand-alone server (not a domain member of course).
***
We have a number of operations to perform:
- Create a CAPolicy.inf file and place it in this location: %windir%
- Install the Active Directory Certificate Services (ADCS) role.
- Run a post-install script that configures certain components.
We'll see more details below.
After all that (since the root CA is offline), we will have to copy the "root certificate" and the CRL from the root CA to the appropriate locations on the subordinate CAs. Indeed, the subordinate CAs cannot consult the offline root CA for certificate revocation checks. We also need to keep in mind that when a certificate is verfied, we have to verify all the certificates in the "certificate chain".
In our case, that would be:
- the root certificate
- the certificate of the subordinate CA
- the certificate issued to the end-user (or computer).
Once again, since the root CA is offline, we have to copy its certificate to the subordinate CAs.
The CAPolicy.inf file
The CAPolicy.inf files provides information used by the certificate authority (root or subordinate) when the CA is installed and when certificate authority certificates are renewed. This file can be more or less detailed. For my PKI, I'll attempt to be as simple as possible.
This is the content of my CAPolicy.inf file (a text file that can be opened in notepad):
--------------------------------------------
[Version]
Signature= "$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy
Critical = 0
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text."
URL = "http://www.mynet.lan/certdata/cps.asp"
[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years
CRLPeriod = weeks
CRLPeriodUnits = 52
CRLDeltaPeriod = weeks
CRLDeltaPeriodUnits = 0
LoadDefaultTemplates=0
-------------------------------------------
Some comments...
[Version] - Signature.
This is normally "$Windows NT$". That's all.
[PolicyStatementExtension] and [LegalPolicy]
I will not address these concepts in detail. In a phrase, a PKI is based not only on hardware and software, but also policies:
A "security policy" is a general presentation of an organization's assets (what we need to protect) and how it is protected. The scope is much broader than the simple implementation of a PKI but may influence the "certificate policy" (CP) and "certificate practice statement" (CPS).
A "certificate policy" (CP) defines the process that an organization uses to validate the identity of those requesting a certificate. This can be as simple as membership in an Active Directory security group or as elaborate as a through background check with a face-to-face interview.
A "certificate practice statement" (CPS) describes how the organization enforces its security policy and certificate policy. This is the document that is referenced in the [Legal Policy] section of the .inf file above.
These documents are crucial if the organization wants other parties to trust their certificates. It is recommended that the legal team be involved in the composition of these documents to ensure compliance with regulations to which the organization may be subject.
In our case, since this is a simple practice network, I will not actually compose the documents above... or consult a team of lawyers to guarantee their legal value.
[certsrv_server]
In this section, we define the length of the key and the validity period of the certificate (in years). For example:
renewalkeylength=2048
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years
So the key length is 2048 bits and the validity period of the certificate is 20 years.
The word "renewal" is important. Intially, we set these values during the CA install process. The values above apply when the certificate is renewed. Even so, the values entered during the install process should match these values.
We also define the CRL period, the time at which a new (updated) CRL must be downloaded. Since the root CA will be offline, we want to make this value rather large, 52 weeks for example, so we do not have to download it manually (via CD or USB key) very often.
We can optionally configure a Delta CRL period (I have not).
Lastly, there are different certificate templates for different certificate usages. We can load them by default (at the time the CA is installed). I will not load the default templates at this time but rather perform this task later manually:
LoadDefaultTemplates=0
Please remember that the capolicy.inf file above is only one example and a simple one at that. Your organization may require something more elaborate.
Once we have created the capolicy.inf file, we must place it in the %windir% folder which is usually:
C:\Windows
Now we can install the "Active Directory Certificate Services" role on the root CA.
Installing the Certificate Services role (ADCS)
I will select various installation options below without necessarily explaining each one (at least not in detail). Some pages will have a "Learn More" link that will explain the choices and make certain recommendations.
First, we open "Server Manger", go to "Roles", and select "Add Roles":
Note: you can click on the images to enlarge them.
Click "Next" on the "Before you begin" page (after you read it) and then check the ADCS role:
Remember that the choice of a name is extremely important. We cannot change it later:
For the root CAs, we can simply select "Certification Authority":
The root CA will be "standalone" (and offline for that matter):
Of course, we need to start with a root CA:
We will opt for a new key since this is a new CA:
For the key character length and the hash algorithm (which I will not explain here), we can choose "2048" and SHA256:
Note: a longer key would be more secure (all other things being equal) but would require more processing power. Each organization will have to consider its specific needs in this area. We can increase the security of the hash algorithm by selecting SHA384 or SHA512. The other SHA options and the MD options would be less secure.
I will name the CA "PKI-ROOT-CA". Each organization must follow its own naming standard. For the DN suffix I typed "MYNET" for the organization and "LAN" for the country although usually we would put a country code here: US, UK, etc..
The validity period of the offline root CA can be fairly long but generally would not exceed 20 years. It is important to remember that, in any case, a CA cannot issue certificates that have a validity period longer than that of its own certificate.
Toward the end of the process, we must select a location for the certificate database and log files. In production, we may want to select locations on a RAID volume for disk redundancy and even place the database file and log files on different RAID volumes. This does not apply to the root CA that will be offline (and probably not even running) but would be a good idea for the subordinate issuing CAs. Each organization will have to evaluate its own needs it this area. Remember that the lack of available CAs could cause the systems that depend on cetificates to stop functioning. For my test network, I have simply created two folders on the C: drive (not recommended for production):
We can review the selected options on the confirmation page:
If all goes well, we should see this:
***
We have not finished with the root CA yet. We still need to execute a post-installation script and then copy the root certificate and CRL to our subordinate CA (or CAs if there are more than one).
That will be the subject of the next blog post.
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 3: configuration of the root CA 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.