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.

12 Comments

  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 ?

  4. Thank you for the write up, this was immensely helpful for me. I was confused about the statement “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.”

    Can you expand on this briefly? I am having a hard time wrapping my brain around why this would be required if the certificates are only used internally. Thanks.

    • In my examples, they were for setting up email and other such services that do require public access to the CRLs, AIA, etc.

      If anything using certificates has even a remote chance of ever needing to reach the CRL or OCSP, but currently does not have that requirement, it’s going to be quite the pain to change everything around.

      Also, having your CRL publically accessible doesn’t have any negative impact. If you can guarantee this need will never arise, then you can probably get away with it.

  5. 1) What about the installation of AD extensions for ADCS? Would these just be to support 2016 domain controllers – even though we don’t have them currently?
    2) Is Windows Server 2016 Datacenter required for this or is Windows Server 2016 Standard sufficient?
    Thanks,
    Chris

  6. This was an incredible series. Thanks for all your efforts.

    I have referred to a variety of sites hoping to complete the configuration on the IIS server. I have spent a few days fighting an error with IIS and thought I’d throw it out here. I have added the Certificate Enrollment Web Service and Certification Authority Web Enrollment roles to the IIS server and stepped through the configuration. I can now browse to /certsrv and authenticate with a username and password. However, everytime I try to create a new certificate, I get “No certificate templates could be found. You do no have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.”

    Again, there are MANY forum posts and blogs about this error, and I have tried just about all the different suggestions to get by this to no avail. Might you be able to shed some light on what might be happening here? I’m SO CLOSE to having this beautiful CA setup in my lab thanks to you 🙂

    Mike

    • I should add that everything else seems to be working, as I was able to get autoenrollment going through AD and a GPO, etc. I can request Web Server certificates all day long through the Certificate MMC. I just can’t seem to get this going through the web interface.

      • Creating certificates in Certsrv requires correct permissions for the user in which you are using to log in to Certsrv… or the user you are logged into Windows as when accessing that web page. As mentioned in my other reply, verify those things first.

    • Thank you for the praise, it’s much appreciated.

      About your issue, in the certificate template on the Security tab, do you have “Read”, “Write”, and “Enroll” checked as “Allow” for the user or group in which you are using to access “certsrv”? These not being checked may prevent them from appearing in Certsrv. Also, make sure you are using Internet Explorer and https.

      Secondly, I’ve seen issues where cert templates do not show up in CertSrv if you have “Archive subject’s encryption private key” check-marked in the “Request Handling” tab.

Leave a Reply

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