Deploy a PKI on Windows Server 2016 (Part 1)

This is the first part of a seven-part series explaining and setting up a two-tier PKI with Windows Server 2016 in an enterprise SMB setting, where the hypervisor (host) is running the free Hyper-V Server 2016, all Certificate Authorities (CA’s) and IIS servers are running Windows Server 2016.

This series was designed for those who are about to, or already have, implemented a production enterprise PKI and to serve as a guide through the process in a real-life manner.  Many other guides are similarly designed, but are more geared towards test environments, using defaults, and not exactly considering real-life scenarios and practices.  My aim is to tie up any loose end questions or needed help regarding the deployment, or to act as a template when trying to troubleshoot existing deployments.

>>> Part 1 (Informational) <<<
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
Part 5 (Distributing Certificates & AutoEnrollment)
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)

PKI Planning

This is the most important step, as it determines how you do everything moving forward.

You must plan carefully, taking into consideration where your PKI implementation may lead down the road.  If you need to make changes later (or sooner), or you found you made a mistake or need to make a change after you have already distributed certificates to users and devices, you will most likely need to re-deploy those certificates.  It depends on what the mistake or change is, of course, but this is usually a huge pain.  Now don’t worry, if it happens or has already happened, I will show you how to get started cleaning it up.

Here are a couple common questions to ask, when using your own certificates for these instances:

  • Will you require public access to your CA services?
    • S/MIME certificates for e-mail digital signatures and encryption
      • If you plan to use it in any way outside of your LAN, such as with Office 365, external users, Outlook clients off-LAN, etc.
  • Will you be implementing DirectAccess?
  • Will you be implementing IPsec or another type of network infrastructure that requires certificates?
  • Will you be implementing Single Sign-On (SSO) or Active Directory Federation Services (AD FS)?
    • Single sign-on with with Office 365, for example.
  • How many users and devices will your PKI support?  This series is directed towards SMBs, but even still…
    • Maybe you need to plan for three-tier, multi-site, or multiple Enterprise CA’s at the second or third tier.
  • Will you need support for SSL certificates for internal web services?
  • Do you want private key archival for the ability to recover Domain user certificates?
  • Will you need to implement OCSP?  Will you want to in the future?

Assumptions and Series Outline

In an effort to prevent this series from growing too large to be immediately helpful, I’m going to write it with a few common assumptions below.  I know this won’t cover everybody’s situation, but I believe it is enough to get you set up and going strong.  This can also serve as a brief non-exclusive outline of what I will be covering in this series.

  • Certificates will need to be validated publicly, as in the S/MIME example above.
  • Running with S/MIME, plus file encryption implementation first, then expanding later.
  • Certificates will be distributed automatically via AutoEnrollment for local Domain users and/or devices, with the ability to distribute certificates to external users who are not on the domain, network, or who may not be local.
  • The PKI will be set up in a typical SMB setting that doesn’t require three tiers, or multiple Enterprise CA’s per tier, but will leave it open as an option.
  • Assuming you care about the security of your CA’s, in that the CA’s themselves will not be directly accessible publicly, and will publish to or put that off to the IIS server.
  • Leave open the possibility that DA, IPsec, SSO, AD FS, and other needs may come in the future.
  • Email users will include Outlook and Thunderbird users on Windows 7 to 10, OSX, iOS, and Android — how to get digital signatures and encryption working on it all.
  • SSL certificates for web servers and services distribution.
  • Private key archival implementation (and recovery) for AutoEnrollment domain users.
    • Although some companies may have policies in place that not allow this, I will cover it anyways.
  • I will not be covering OCSP immediately in this series.  In a typical SMB, there are no performance benefits to using OCSP, as the CRL files will be so tiny.  I will, however, add it in and link to it later.
    • Newer Windows prefer OCSP over CRLs first, but regardless, I will still add it later.
    • OCSP info is in certificates, so if you implement it later, it will only effect new certificates.

The Design

Here I will lay out the design, and briefly explain some how’s and why’s.

  1. Off-line, Off-domain Root CA
    1. Domain-joined Enterprise (issuing) CA
    2. Domain-joined IIS server

Root CA

The Off-line off-domain RootCA is turned off, and kept off, after the Enterprise CA (issuing CA) is set up.  You may take it a step further and move the RootCA virtual machine off the host entirely, to some form of “in the cabinet” storage.  This is done to pretty much guarantee it’s security.  If the Root CA is compromised, the entire PKI; all certificates at every level, are also considered compromised.  At least if a subordinate or enterprise CA is compromised, only the certificates distributed by that CA are considered compromised.

The off-line RootCA is only to be turned on in the following cases:

  1. If you need to renew the Root CA or Issuing CA (tier 2) certificate.
  2. You need to add another 2nd tier Enterprise or Subordinate CA.
  3. A second tier CA is compromised and you need to revoke it’s certificate.
  4. To renew or republish the Root CA’s CRL (certificate revocation list).  Root CA’s really do not need Delta CRLs.
    1. You would need to renew / republish this if you haven’t changed the “CRL publication interval” of the Root CA.  In that case, you would need to turn it on periodically to republish at default interval.
      1. To overcome this, set it to a high number such as 10 or 20 years (the same or lower than the expiration of your Enterprise CA’s certificate).  If you happen to revoke a 2nd tier CA certificate in the meantime, then you can simply turn it on and republish the CRL.

Enterprise CA

The domain-joined Enterprise or Issuing CA’s job will be to only issue certificates, and to publish CRL’s and Delta CRL’s (to the IIS server) at an interval that works best for your environment.  We don’t want a CA accessible from the internet, or to be responsible for certificate CRL look-ups and other web services.  I like to deploy it like this to keep the CA’s safer.

IIS Server

The domain-joined IIS server will be the server providing all other services.  This is where the Root CA and Enterprise CA will publish their CRLs (the CDP), where the AIA will link to, and what the CRL url will point to on all certificates (unless you will host it somewhere else).  Because of this, you will want to make sure the locations are publicly accessible URLs.  Even if your IIS server is not publicly accessible, you still need to use publicly routable URLs in anything you include in the certificates themselves.  I will explain this better later in the series, but you can always copy the CRLs and Delta CRLs to the publicly accessible web server where the CRL and AIA urls point to on the certificates.  This IIS server is also where the CertSrv service will be hosted.

Next Steps

Now that we have some of the more important background and information out of the way, the next step is to set up the servers.


  1. sometechstuff

    Thanks for this info. It is real helpful. I have my Server 2016 PKI and have SCCM woking as well. Beyond SCCM, I would like to use my PKI for some of our intranet sites. For example, I am setting up an iPrint server (no internet access) so users can self install printers. My collegues are telling me we can’t use our PKI. Since all I have ever used it for is SCCM, I can’t confidently argue my point. In addition, I’m not clear how to use it for sites other than SCCM. Any info is appreciated. Thanks

    • Timothy Gruber

      I’ll be covering the creation of certificate templates for the use of intranet websites. If you have an existing PKI, you can issue web certificates for any local web server.
      Does your colleague share why he thinks you can’t use your existing PKI for intranet sites? That is one of the major uses of an internal PKI. They serve certificates for so many different things.

  2. sometechstuff

    Thanks again,
    When you state “I’ll be covering the creation of certificate templates for the use of intranet websites”…are you saying you be covering it in one of the 7 steps above or in future posts?
    I think my collegues are questioning it because it is unknown to them…and mostly to me as well. I look forward to reading your posts.

  3. Can you discuss an environment with multiple issuing CAs ? We want to have (3) Issuing CAs (one for each geographic location). How do we influence which CA clients will use ? As I understand it, CAs are not based on Active Directory site structure ?

Leave a Reply

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