Saturday, February 21, 2015

PKI (Public Key Infrastructure) with ADCS, Part 4: configuration of the root CA (continued)

In my previous post, we created a capolicy.inf file, placed it in the %windir% and then installed the Active Directory Certificate Services role, configuring our first server as the organization's "root CA" (certificate authority).

We will now finish the configuration by running a script that defines certain settings, in particular those for CRL Distribution Points (CDP) and Authority Information Access (AIA):


::Post-install script for Root CA

::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz

::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"

::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

::Apply the required AIA Extension URLs
certutil –setreg CA\CACertPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n

::Apply the required CDP Extension URLs
certutil –setreg CA\CRLPublicationURLs "1:%WINDIR%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n
2: %%3%%8%%9.crl"

:: Enable discrete signatures in subordinate CA certificates
certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1

::Enable all auditing events for the MachLinkIt Root CA
certutil -setreg CA\AuditFilter 127

::Restart Certificate Services

net stop certsvc & net start certsvc


First, two remarks:

The "CDP" is the "CRL Distribution Point". This is a section (or "extension") in the certificate's properties that (in the form of URLs) indicates where the certificate revocation lists are published. Common options include Active Directory or a web site. Remember that this list must be consulted so revoked certificates cannot be used to grant access to resources.

The "AIA" (Authority Information Access) section of the certificate properties indicates where the issuing CA's certificates are published. Applications consult these URLs when building what is known as a "certificate chain". In practice, the application will verify not only the certificate presented by the end-user (or computer) but also the certificate of the CA that issued the end-user certificate.

Note: of course, the reader will adjust the domain and organization names as appropriate. Using "machlinkit" will not produce good results in your network!

Now let's take a look at each section of the script:

certutil -setreg CA\DSConfigDN CN=Configuration,DC=machlinkit,DC=biz

This line defines the name of the Active Directory configuration partition. It is essential. I omitted it once when first learning about PKI and such an omission will prevent proper PKI operations.


certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"

These lines define the CRL publication interval. At the end of the period defined, it is expected that a new CRL be published. The Delta CRL is optional and I have opted not to use one.


certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

This section defines the validity period for issued certificates (and NOT the validity period of the root certificate which was configured earlier during ADCS installation). In essence, it means certificates issued to the subordinate CAs will be valid for 10 years.


CDP and AIA sections (please see script above)

These two sections are by far the most complex. A detailed description of all the options is beyond the scope of a simple blog post, so I will refer the reader to the sources indicated in the first blog post of this series.

I will say that the resulting settings are appropriate for a root CA.

These settings correspond to those in the "Extensions" tab of the root CA properties. We can view them in the Certificate Authority console. Enter "certsrv.msc" in the search box (Start | Search Programs and Files).

For AIA, nothing is configured for the local C: drive. Even with online subordinate CAs, this location cannot be accessed by applications seeking to construct a certificate chain. This is obviously true for an offline CA as well.

On the other hand, we will want to indicate a URL so certificates can be stored (and consulted) in Active Directory and on a web server (next two screenshots):

For the CDP, we will publish the root CRL to the location below:

And here are the CDP settings for LDAP and HTTP:

Yes, as the screenshots above suggest, this all can be configured manually. The script has the advantage of allowing us to (re)apply a consistent group of settings.

As for the final sections, we enable discrete signatures, auditing (both optional) and then restart Certificate Services so the settings take effect.


True, what we have just presented above appears complex and can be confusing. Some readers may have questions. For example:

"We published a CRL to a location on the C: drive of the offline root CA. Since it is offline, how can this CRL be accessed?"

"We've configured the CA with indications (URLs) that designate the locations at which its certificate can be consulted. Once again, how is this possible if the root CA is offline?"

These questions form an excellent transition to our next steps.

Since the root CA is offline, we must copy both...

  1. the certificate of the root CA (and)
  2. the CRL of the root CA

and publish them manually at the locations indicated above:
  1. in Active Directory
  2. on the website designated by the HTTP URL. This website can be hosted on the subordinate CA itself - or elsewhere.
The certificate of the root CA as well as its CRL can be found here:


We can copy these two files to a flash drive or burn them to a CD/DVD and then place them in the locations indicated above on the subordinate CA.

Once we complete the installation of this subordinate CA, those operations will be the subject of my next blog post.

Thursday, February 12, 2015

PKI (Public Key Infrastructure) with ADCS, Part 3: configuration of the root CA

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):


Signature= "$Windows NT$"

Policies = LegalPolicy
Critical = 0

Notice = "Legal policy statement text."
URL = "http://www.mynet.lan/certdata/cps.asp"

CRLPeriod = weeks
CRLPeriodUnits = 52
CRLDeltaPeriod = weeks
CRLDeltaPeriodUnits = 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.


In this section, we define the length of the key and the validity period of the certificate (in years). For example:


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:


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:


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.

Tuesday, February 10, 2015

PKI (Public Key Infrastructure) with ADCS, Part 2: more concepts and description of test network.

In the following lines, I will present the test network used to explore various aspects of a Public Key Infrastructure (PKI) deployment.

Active Directory considerations

In the test network, we will implement a "two-tier" enterprise PKI with two levels of "certificate authority" (CA) servers. This type of PKI requires Active Directory.

Note: such a topology is in contrast with a "stand-alone" CA, comprised of a single server, which can function without Active Directory. More details are below in the section "Number of tiers".

We will use what is perhaps the most common Active Directory topology: a single forest with a single domain.

All our domain controllers run Windows 2008 R2 and we have a Windows 2008 R2 level schema.

Domain and forest functional level (DFL and FFL) are at Windows 2008 R2.

We will implement a PKI based on Windows 2008 R2 servers.

Note: other Active Directory topologies, schemas, domain and forest levels may vary. It is not my objective to examine all possible scenarios in which one might want to implement PKI. If your network is different in those respects, I would invite you to consult other resources on the subject, such as the references cited at the end of this post.

It is best practice to install the certificate authority role on servers that are not domain controllers and that do not hold any other roles. Other scenarios are possible and even supported but can complicate management.

Naming conventions

This is extremely important because we cannot rename CAs.

Besides the name of the CAs, we may want to name security groups, Organizational Units and GPOs related to the PKI, with a name that reflects this relationship.

For example:

  • PKI-Root-CA for the offline root CA (there is only one)
  • PKI-Sub-CA-1 for the first subordinate CA (it could also be designated as a policy or issuing CA).
  • PKI-Servers = OU for servers with a PKI role.
  • PKI-Admins = security group for PKI administrators

Number of tiers (or levels)

A PKI topology can consist of a single server or include many servers organized in a multi-level (or tier) hierarchy.

A single certificate authority (CA) is rather simple to install and may be perfect for a small organization that wants to use certificates for a particular purpose but cannot justify the cost and effort of configuring a more complex topology.

There are disadvantages, however, that may be significant.

First, the server cannot be taken offline (since it must be available to issue certificates and respond to inquiries about certificate validity). But taking a server offline, or rather never placing it online to begin, is the preferred method to secure a root CA and guarantee the integrity of the root certificate.

Second, a single server (this is true in general) cannot provide high availability. This is a more significant limitation than one might think at first glance. If the server is "down", certificates cannot be issued, of course, but worse, the validity of certificates already issued cannot be verified.

In essence, clients to which certificates have been issued, will query the CAs on a regular schedule to discover if any issued certificate has been revoked. This process can be somewhat complex but, in the end, if a certificate server is not available for a certificate revocation check, the issued certificates will stop working (sooner or later). This means that the services using those certificates will also cease functioning. That could be wifi access, encyption and decryption of email, or building entry with a smart card.


I will opt for what is known as a "two-tier" hierarchy with a total of two certificate authority servers (CAs): one offline root CA and one subordinate CA. In this case, the subordinate CA will also be an "issuing" CA because it will issue certificates to the various entities (users, computers, network devices) that request them.

Concerning the number of CAs, and their organization, we have to consider factors such as...

  • Number of certificates (if many certificates are requested we may need more CAs)
  • Availability - having more than one server is crucial here but we also need to consider reliability between sites. We may need a CA per site to ensure availability.
  • Management style: if each team or each department intends to manage its own certificates, more CAs may be necessary than in a centralized environment (one team manages the PKI).
  • Politics (or regulation). Legislation in the USA may be different than legislation in the EU. Multinational companies may have to consider this element.

In my network, however, two CAs should suffice to explore the aspects of PKI that interest me.

Proper planning also supposes that we answer questions about the following requirements (I will simply summarize, please see sources listed below, and Brian Komar's book in particular, for details):

  • Applications. What systems will use the certificates: website authentication? encryption/decryption  of email? Code signing? Smart Cards?
  • Security. Do we need to place the root CA offline? Should we take additional measures to protect CA private keys? What determines if we approve a certificate request or not?
  • Business. What will the PKI cost? To what extent can we minimize cost while providing expected level of service? What is our liability in case of certificate compromission?
  • External. If we want to interact with a partner organization or a government, there are other considerations.
  • Technical (administration): 
  1. Who will manage the PKI?
  2. Will there be separation of roles?
  3. What kind of storage will be use for the CAs?
  4. What key length will we use (1024, 2048, 4096)? As a general rule, longer key is more secure but requires more computing power. 2048 in currently the recommended minimum.
  5. What will the validity period of the certificates be?  

Some more details on these technical aspects...

Management of the PKI

With Windows 2008 R2 (and previously 2008), the management of the PKI can be separated among four roles:

  • CA administrator ("Manage CA permissions") -> this role manages the entire CA.
  • Certificate manager ("Issue and manage certificates") -> manages certificates: issuance, revocation, archiving.
  • Backup operator -> backup and recovery of CA databases and configuration files.
  • Auditor -> review PKI related logs, including Event Viewer.

If only one person manages the PKI, then obviously that person has all these roles.

Validity period of the certificates

A common practice is to start with the preferred lifetime of the issued certificates (5 years, for example), make the certificates of the subordinate CAs twice that duration (so 10 years) and the certificate of the root certificate twice the lifetime of the subordinate certificates (20 years). 



Windows Server 2008 PKI and Certificate Security, Brian Komar, Microsoft Press, 2008

Text is out of print.

It is possible to obtain a digital copy. See details here:

Komar Consulting

TechNet Security forum

Designing and implementing a PKI - Directory Services Team (Ned Pyle)

Saturday, February 7, 2015

PKI (Public Key Infrastructure) with ADCS, Part 1: Introduction

PKI ingredients

My next project is to explore "PKI" using Active Directory Certificate Services (ADCS).

First of all, what is PKI? And how does it work?

Public Key Infrastructure is a system that manages digital certificates.

This includes requests for certificates by various entities (users and computers), delivery of certificates to these entities, the possible revocation of the certificates and storage of the certificates.

Ingredients of PKI include hardware (servers), software (Active Directory Certificate Services, for example), administrators, and a set of policies governing the use of the system.

Brian Komar includes the following among the "building blocks" of PKI:

  • Certificates
  • Certificate authorities
  • Certificate revocation lists (CRL)

To paraphrase, "certificates are electronic representations of users and computers [...], issued by a certificate authority (CA), [and] associated with a public and private key pair."

From "PKI and Certificate Security" (Brian Komar, Microsoft Press, 2008, p. 21)

Certificates have been compared to "digital passports" - and governments to certificate authorities.

Certificate authorities are a combination of hardware and software that issue certificates, managed by administrators who regulate the distribution of certificates and can revoke them as well - just like a government can revoke a passport.

The CRL is the list of revoked certificates that clients consult so these revoked certificates cannot be used to access a network (for example).


Now let's take a closer look at each of these "ingredients" of PKI.


Once again, a certificate is a digital passport that proves the identity of a user or computer (or service, network device, driver or software code).

A certificate exists in the form of a small file, literally  a couple of kilobytes in size.

Certificates are based on a standard called "X.509" and have evolved over the years. Modern certificates contain information such as:

  • the subject of the certificate. This is the name of the user or computer that the certificate represents (like the name on a passport).
  • information about the certificate authority (CA) that issued the certificate (just like the passport authority that delivered the passport).
  • the "public key" (please see the explanation that follows)
  • the serial number of the certificate (this distinguishes it from other certificates issued by the CA).
  • the validity period of the certificate (in particular, when it expires - and needs to be replaced)
  • key usage or "what the certificate can be used for": data encryption, software code signing and so forth.
  • the "CDP" or "CRL distribution points". This is where systems (to which the certificate is presented) can verify that the certificate has not been revoked.
  • the "AIA" or "Authority Information Access". This is the location where the certificate of the issuing CA can be found.

Concerning the "AIA", certificate authorities typically function in a hierarchy where a well-secured "root certificate authority" (essentially a server) issues certificates to one or more subordinate certificate autorities (other servers) that issue certificates to end-users. All these certificates must be verified as valid for the authentication of the user (or computer, etc.) to be successful.

So what is a "public key"?

This has to do with encryption.

There are three ingredients to encryption.
  • the message or text we want to encrypt
  • the algorithm used to encrypt the text
  • the key: in simplest terms, this is the password (passphrase) we enter when encrypting and then decrypting the message. In reality, it can be much longer than a word or even a phrase.

There are two main types of encryption:
  • symmetric encryption
  • asymmetric encryption

With symmetric encryption, the same key is used to encrypt and decrypt the message.

Examples of symmetric algorithms include DES (obsolete), DES3 and AES, which is one of the most current and commonly known standards (there are others).

Symmetric encryption has one disadvantage: once we encrypt our message, we have to send the key to the recipient so they can decrypt the message. Most often, this is not practical. Obviously, we cannot send the key with the message, since anyone intercepting the message would have the key that decrypts it!

Asymmetric encryption uses two different but related keys: a private key and a public key.

The owner of the private key keeps this key secure but makes the public key available.

What is encrypted with one key can only be decrypted with the other.

If I want to send an encrypted messages to someone, I obtain their public key (made available to the public), encrypt the message and send it to the recipient.

But what if someone else has the recipients public key? After all, it is public (at least if one knows where to look).

It simply does not matter: only the private key can decrypt what the public key has encrypted (and not another copy of the public key).

So as long as the private key is secure, the message remains protected.

Two common asymmetric algorithms are "Diffie-Hellman" (named after the inventors) and RSA (Rivest Shamir Adleman).

In fact, there is no opposition (or "rivalry") between symmetric and asymmetric encryption. Most often, the two types of encryption work together. Asymmetric encryption, using the private key/public key pair, encodes the key that is used for symmetric encryption.

Why not just use asymmetric encryption, since it apparently avoids having to expedite an identical key to the partner?

Symmetric encryption and decryption is hundreds (even thousands) of times faster than asymmetric. For a simple phrase, it would make no difference, but when transmitting large amounts of data, it is better to use asymmetric encryption to transmit the symmetric encryption key and nothing else. 

Lastly, applications use these algorithms to encrypt (or digitally sign) messages. Strictly speaking, the algorithms do not encrypt or decrypt all by themselves.

There is abundant information online about encryption. For further information, I would conduct a search for "encryption" or "how encryption works" and select the results most appropriate for your skill level.

Certificate Authority

The certificate authority (CA) is essentially a computer (a server) but also involves the intervention of administrators who either approve certificate requests manually or configure a mechanism for automatic certificate delivery.

The CA performs these tasks:

  • Verification of the identity of the user/computer requesting the certificate.

This verification can consist in responding to an email sent to a mailbox that only the legitimate requestor would normally have access.

It can depend on the user (or computer) belonging to a particular Active Directory security group and thus having the right to request - and obtain - certain certificates.

In some cases, the certificate manager (the person in charge of the CA) would meet with the requestor face-to-face and require a form of identity (passport, driver's license).

  • Delivery of the certificate to the requestor

  • Revocation of certificates

For example, an employee uses a smart card, in which their certificate is electronically embedded, to access a secure area. The employee looses their smart card. The CA must revoke the certificate so it can no longer be used to grant access, and make available an up-to-date list of revoked certificates that the authenticating devices can consult.  

The certificate authority can be a single server but most often involves several servers organized in a hiearchy of two to three levels (or tiers).

At the summit of the hierarchy, we have the "root CA".

At the lower levels, we have "subordinate CAs". They can be "intermediate CAs" that issue certificates to another level of CAs or issue certificates directly to users or computers. In this case, we call them "issuing CAs".

Most often, a two tier hierarchy is sufficient but it is possible to have a single CA (in very small PKI implementations) or even more than two or three tiers in very large and complex implementations.

CRL (Certificate Revocation Lists)

As already mentioned, it is sometimes necessary to revoke a certificate because it has been compromised. The CRL is a list of all revoked certificates.

There are two types of CRLs:

  • base CRL: a complete list of all revoked certificates
  • delta CRL: a list of certificates revoked since the last base CRL was published.

Only a base CRL is absolutely necessary. The delta CRL, smaller by nature, can be useful if the base CRL is very large and we have limited bandwidth.

OCSP (Online Certificate Status Protocol)

Since Windows 2008, there is a new variation to the consultation of the CRL by clients. OCSP servers obtain a copy of the CRL and clients query the OCSP server instead of the CA. The OCSP server (also called OCSP responder) consults the CRL on behalf of the clients and lets them know if the certificate in question has been revoked. OCSP represents an additional level of complexity but avoids the need to download (repeatedly) potentially large CRLs.

Regardless, OCSP is optional.


Lastly, Active Directory Certificate Services (ADCS) is the Windows Server Role that allows us to deploy the Microsoft version of PKI.