This is the first part of a seven-part series explaining and setting up a two-tier PKI with Windows Server 2016 or Windows Server 2019 in an enterprise SMB setting, where the hypervisor (host) is running the free Hyper-V Server 2016 or Hyper-V Server 2019, all Certificate Authorities (CA’s) and IIS servers are running Windows Server 2016 or Windows Server 2019.
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.
- S/MIME certificates for e-mail digital signatures and encryption
- 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.
- Off-line, Off-domain Root CA
- Domain-joined Enterprise (issuing) CA
- 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:
- If you need to renew the Root CA or Issuing CA (tier 2) certificate.
- You need to add another 2nd tier Enterprise or Subordinate CA.
- A second tier CA is compromised and you need to revoke it’s certificate.
- To renew or republish the Root CA’s CRL (certificate revocation list). Root CA’s really do not need Delta CRLs.
- 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.
- 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.
- 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.
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.
I was happy to find your article and began following it thru the process. I was disappointed to learn that you stopped after step 5 and have not completed it as of yet. I think it would be a great idea if you would place a note at the top of Part 1 telling unsuspecting people that you have not completed the article. This way they could decide for themselves if they wish to go down the path you have laid out.
Given that the IIS Web Server is not a CA itself, will I be able to access the webserverfqdn/certsrv page after installing the Web Enrollment feature and have it actually request a certificate from the Enterprise CA? I’ve tried to set this up, but I’m getting nowhere.
Additionally, my employer has infrastructure where with any website I visit, you can view the cert and see the company’s Intermediate and Root. So it must be generating a certificate on the fly for all web servers so the company can perform SSL Decryption.
Is that something this infrastructure you’ve outlined can perform? Not the decryption itself but the on-the-fly certificate generation?
You will need to create a sub-ca for MIM proxy/SSL decryption. Most products have guides on how to do this. Forcepoint for example has a guide:
https://www.websense.com/content/support/library/web/v85/wcg_help/ssl_sub_ca.aspx
This is a very well written guide. For the Root, you do not mention HSM, do you think a big company can do without? It is being pushed by the ‘known’ PKi experts. No disrespect intended. But I am a bit uncertain on this subject I just was wondering if what you describe could be sufficient to do without the extra cost? Some HSMs are connected to the network go even further and protect the issuing CA’s keys as well, what is your general opinion on the security vs. cost, is it worth it?
I would think it depends on the company’s existing policies and practices. Certainly you could do without HSMs. Personally, I don’t see a big benefit vs cost.
Hi Timothy, I used this guide to get my PKI up and running, thanks. I need to install CEP and CES also. Do you think that would be best installed on the EntCA or the web server?
I thought I’d also give some background. I’m using the PKI for EAP-TLS wireless authentication. I’m successfully authenticating domain Windows clients. But now I’m trying to get MacOS, IOS, and Chromebooks authenticated. All of these devices are school-owned so they are on our private network. From what I can tell, I’ll need Certificate Enrollment Policy and Web services installed.
I posted this question to the MS forums. One person replied and said they installed CES and CEP on the web server node of their PKI. That makes sense to me, I guess I’ll go with that.
Very interesting guide! Actually, this can also be performed using OpenSource software, such as XCA (https://sourceforge.net/projects/xca/) for the Root CA and EJBCA (https://ejbca.org) or ReTrustMe PKI (https://retrust.me) for the issuing CAs.
It’ll be probably easier on lots of topics, though the integration with Microsoft world will require slightly more efforts.
Yes, but in the case of taking advantage of MS Active Directory automation such as automatic domain user and computer renewal and other such features, those my not work or integrate as easily.
But they are great solutions if you just need a PKI.
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.
Make the iis server(the computer account) has permission on the template u created. You can use an AD group and keep adding web servers in that group as required. This would need a restart of the machine to reflect the group. Also if you are using /certsrv you will only see Schema ver 1 and 2 certificates.
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
Did you ever get an answer? I’m trying to determine the same thing.
Which extensions are you referring to?
For a full PKI, Datacenter edition licensing is not required. Windows Server 2016 Standard edition is fully sufficient.
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.
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 ?
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.
I’ll actually stick it in Part 5 or Part 6. I haven’t decided yet.
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
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.