A Microsoft PKI Quick Guide – Part 2: Design

If you would like to read the other articles in this series please go to:

If you would like to be notified when Martin Kiaer releases A Microsoft PKI Quick Guide – Part 3, please sign up to our Real time article update newsletter.

We have now gotten to our second article in our Microsoft PKI quick guide four-part series. In our first article we gave you a quick overview on how to prepare and plan your Microsoft PKI. In this article we will get a bit more technical. We will look at some PKI design issues. Throughout this article we will show you how to avoid common mistakes during the design phase.

Designing a PKI

When you are designing your PKI, there are a few things you should consider:

  • How should your CA hierarchy look like (e.g. number of CAs and what their roles should be)
  • How do you want to protect the private keys of the CAs
  • Where should you create the publication points

Let us take a closer look at each of these design issues.

Designing a CA hierarchy that scales well

The numbers and levels of CAs you should implement basically depend on your security and availability requirements. You should try to organize your hierarchy according to your needs. There really isn’t a best practice guide in terms of how many CA levels you need, although it is extremely rare that anyone needs 4 or more levels; however there is a rule of thumb which we have listed in table 1 below that may be able to give you a good push in the right direction:

CA Level


  • Low security
  • Lower security requirements for CA security
  • Consists of a single root CA
  • Small number of certificate requests

  • Medium security
  • Consists of an offline root and online subordinates
  • The offline root CA is removed from the network
  • The Issuing online CAs remains on the network
  • Two or more CAs to issue each certificate template is recommended

  • High security
  • Consists of offline root and offline policy
  • One or more online issuing subordinates
  • Suits larger, geographically distributed, or high security organizations

Table 1: Number of CA levels needed

As an additional note, you may recall from the first article, that there was something called a certificate policy which describes how and who will issue and distribute certificates to a subject (e.g. subjects being users, computers, devices etc.). If you ever believe that you may need more than one certificate policy, due to legal, geographical, organizational or certificate based usage, then you will definitely need a 3-level PKI hierarchy, since this requirement will require 2 or more policy CAs at level 2 (also known as the policy CAs).

When you implement a PKI, you will always have to start with a root CA, no matter whether we deal with a 1-level, 2-level or 3-level PKI hierarchy. Since the root CA always will be the root of trust, and most often implemented by using a self-issued certificate, it is essential that you protect the root CA’s private key the best you possibly can. This should always be the case, no matter how many levels your PKI hierarchy consist of. If your PKI hierarchy consists of 2 levels or more, then your root CA requires a minimal amount of access, since it will only be the subordinate CAs that require access to the root CA. However, as the distance from the root CA increases (i.e. more levels are added), the security requirements decrease and the access increases with respect to the subordinate CAs. This will be an important factor when we have to start installing the CAs, which we will explain later in this article.

CA private keys

Before you start installing a CA, you should have a plan for what the size of the CA’s private key should be and also how it should be protected. Let us start by looking at the key size, which is very important for both security and compatibility reasons. Table 2 below lists the recommended key sizes:

CA role

Key size

Root CA


Policy CA


Issuing CA


Table 2: Recommended CA key size

Normally, a key size of 4096 would be recommended for security reasons, especially for the root CA. However this may create all sorts of incompatibility problems with for example Cisco based network products (depending on what version of Cisco IOS is being used). This is due to the fact that many 3rd party products have problems handling key sizes larger than 2048. And since network equipment can be integrated in solutions such as 802.1x for validation and compliance, key size will matter. So make absolutely sure that you know what equipment will be used and what limitations there may be with respect to certificate handling, before you start your PKI implementation.

Once you have defined the CA key size you want to use, it is time to look at how the CA private key should be protected.

Protecting the CA private key

By default, the CA uses Microsoft’s strong Cryptographic Service Provider (CSP) and protects its private key with the help of the built-in Data Protection API (DPAPI). This poses a problem, since all members of the local administrators group have access to the CA’s private key and any member of this group can export the CA’s private key and thereby create a new fake CA that can issue fake certificates. Other security challenges exist such as buffer overrun attacks from malicious software.

So what should you do? Well the best answer is “it depends”. You will have to balance your security requirements with the costs and usability associated with the protection of the CA’s private key and it is often the CA hierarchy which dictates your options. In table 3 below, we have listed some of the most common ways to protect a CA’s private key. We will leave it up to you to work out a risk assessment in terms of how you best protect the private key of your CAs. Just remember that this is probably the most important component to protect with respect to your PKI.

Protection  method

Pros (+)

Cons (-)

Local Certificate Store

  • Easy to implement (default)
  • Low cost

  • Low security
  • Built-in CSP is only FIPS 140-1 compliant

Chip based authentication (Smart Card or USB Token)

  • Fairly easy to implement
  • Low cost
  • FIPS 140-2 compliant

  • Low physical security, because smart card or token can be easily lost or stolen
  • Requires physical presence when Certificate Services is started
  • Requires special CSP that is both FIPS 140-2 compliant and supports Microsoft Certificate Services

Encrypted Virtual machines

  • Easy to implement
  • Low cost
  • Not hardware dependant
  • FIPS 140-2 compliant

  • Medium security
  • Vulnerable to analog attacks, because hard drive or DVD containing virtual machine can be easily lost or stolen

Hardware Security Module (HSM)

  • Very high security
  • FIPS 140-2 Level 2 and 3 compliant
  • Can be either PCI or LAN based
  • Can often be used as SSL accelerators as well

  • High cost (depending on configuration)
  • Requires careful and default planning

Table 3: Some of the most common ways to protect a CA’s private key

In addition to the recommendations listed in table 3, you also want to increase the security of the CAs by making sure that all CAs, except for the issuing CAs are kept offline. By this we mean that they should at least be off the network and only connected to the network whenever the CRL and issued certificates for all CAs in your entire PKI needs renewal. Mostly, the root and policy CAs are turned off entirely, but again, this should depend on how well your physical security is and how the CAs’ private keys are protected as well as how reliable your hardware is.

Where to create the publication points

The last area we will focus on before we start the PKI implementation is the publishing location for Certificate Revocation Lists (CRL) and the CAs’ public keys. This is known as the Certificate Distribution Points (CDP). There are different protocols which we can use to define the CDP and they are:

  • HTTP
  • LDAP (which in the Microsoft world normally means Active Directory)
  • FTP
  • File share (SMB)

In figure 1 below, we have illustrated where to publish the CRL and CA public keys along with the recommended protocol order for the most common protocols.

Figure 1:
Recommended CDP protocol order (click here for larger image)

As you can see, the recommended primary protocol should be HTTP and there is a good reason for this. HTTP is recommended because it is the best protocol for both internal and external publication points. HTTP is perfect if you need to issue certificates for both internal and external users at the same time. Especially external usage is important to consider, since you would want to make sure that certificates used for VPN, NAQ or Wi-Fi access are checked for revocation, before the users are allowed access to your internal network. It is also important to note that if a CDP is not available for a given protocol, then it will time-out (usually after 30 seconds) and move on to the next protocol on the list. So by having the correct configuration from the beginning, you are delivering a great user experience, since the CRL can be checked from internal and external locations without the time-out issues and without compromising your network security setup. However, if you for one reason or another should choose the default protocol which is LDAP, then there is nothing wrong with this, especially if your PKI is only going to be used for internal purposes. Just beware that if you are using an Active Directory integrated PKI and you issue certificates to external users, then it will require that they be able to perform LDAP queries to your Active Directory (assuming you use Active Directory as a CDP LDAP repository).

You should however also make sure that you have a redundant web server setup, using a DNS round-robin setup if your preferred protocol is HTTP. If you want to use LDAP, then you already have a redundant setup if you have two or more domain controllers in your domain.


In this article, we have given you some quick guidelines and best practice advice on how best to design a PKI consisting of a combination of both offline standalone CAs and enterprise based online issuing CAs. We highly encourage you to study the tables and figures in this article, since they contain a lot of small best practice details, which we have only briefly touched. In our next article in this PKI quick guide series, we will use our design best practices from this article and show you how to install a PKI using a step-by-step approach.

External resources

This article series is done with the help from a lot of great resources. All the excellent Microsoft PKI articles are collected in one place which you can find on the Microsoft PKI Web Portal

Want to see how Microsoft does PKI, then check out the IT Showcase -Deploying PKI Inside Microsoft

And this is a great book – Microsoft Windows Server 2003 PKI and Certificate Security

If you would like to read the other articles in this series please go to:

If you would like to be notified when Martin Kiaer releases A Microsoft PKI Quick Guide – Part 3, please sign up to our Real time article update newsletter.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top