It’s been over a year since I’ve last posted and that’s primarily because of life smacking me straight in the face. Between studying for college, certification exams, and the recent news of our Baby Girl on the way, I just haven’t had the time to sit down and write a meaningful and well thought out post.
In the months since my last post, I’ve also added some pretty cool certifications to my resume, most of them I actually did within the last month:
- ITILv3 Foundations
- CompTIA A+ (I know, really? Part of my degree program)
- EC Council Certified Encryption Specialist (ECES)
- ISC2 Systems Security Certified Practioner (SSCP)
Next weekend I’ll be taking the ISC2 Certified Cloud Security Professional (CCSP) Exam, so I should be adding that one to my resume as well. I’m excited and enjoying focusing a lot more on security than networking, the enjoyment I got out of networking had begun to grow stale.
I still find a good amount of enjoyment out of it, but not the amount I used to where I would often find myself up for 3 days straight off of the pure chemical rush of learning and labbing things out.
Turn’s out you’ll wait no more. Today’s discussion will be part 1 of a multi-part discussion on PKI. This post will primarily focus on building a two-tiered PKI infrastructure using Active Directory Certificate Services.
Here’s what the other parts will cover:
- Part 1 – Building a Two-Tiered PKI
- Part 2 – Configuring and Setting Up Smart Card Logon and Smart Card based EFS
- Part 3 – Configuring Automatic Enrollment and Certificate Selection for RDP
- Part 4 – Federating login with Office 365 and Providing S/MIME functionality with your on-prem PKI
- Part 5 – Forget Smart Cards; FIDO, TPM VSC and more
Before I get too far ahead of myself I want to make it clear that I’m assuming you already have an understanding of Asymmetric Cryptography and PKI and because of that, I’ll only describe it with three bullet points:
- Asymmetric Cryptography – data is encrypted with a different key than it is decrypted with.
- PKI enables functional Asymmetric Cryptography by providing a backend to validate, issue, revoke and publish certificates to a directory
- In an asymmetric cryptography environment, users have both a private key and public key. Data encrypted with the public key of a user can only be decrypted using that same user’s private key.
- For Example:
- Jane wants to encrypt data to Send to Jon; neither Jane or Jon have exchanged private keys to encrypt the data.
- Jane will instead reference Jon’s public key stored in their local directory. Jane will encrypt the data using Jon’s public key and also sign the data with her private key.
- When Jon received the data, he will decrypt the data with his private key, and reference Jane’s public key to validate the digital signature.
The above is a simple example of how such encryption would work. There are a few key distinctions made in this example that I want to highlight before moving forward.
- Digital Signatures can only be signed by the owner of the private key.
- Digital Signatures are proof of origin, and in some instances provide evidence of non-repudiation.
- Digital Signatures are validated using the user’s public key.
- Encryption of data is only possible using the recipient’s public key.
- The decryption of data is only possible using the recipient’s private key.
- In either instance, there is a key-pair generated that contains both the private and public keys. Generally speaking, only the user will maintain possession of the private key. Public Keys are normally published to a Global Address List (GAL) or in Active Directory
For our setup, we’ll be using a simple two-tiered PKI for an enterprise environement. There won’t be a whole lot of things going on, but we’ll show you how to get this setup and working in your environement. The two Certification Authorities we’re going to be creating are:
- Scorchedwire Media Group – Root CA X1
- Scorchedwire Media Group – Subordinate CA G1
Based of the names, I’m sure you’ve already made the assumption that there’s some heirarchy here to this setup. This is normal in any PKI.
- The Root Certification Authority is responsible for issuing certificates to Subordinate Certification Authorities.
- The Root CA should remain off at all time, other than to patch, manage certificates (issue/revoke) and to periodically publish CRLs.
- The Subordinate CA will be used to manage all server and user certificates, not including CAs.
- The Subordinate CA will publish the Root CAs CRLs.
Wait, you mentioned CRL, what’s that?
When a CA revokes a certificate prior to the expiration, a new entry to the servers Certificate Revocation List (CRL) is created. The CRL is what provides systems with the information necessary to establish whether the certificate is valid or not.
Let’s Get Started
To start, I’ve already deployed to Windows Server 2016 Standard VMs. When deploying these VMs, here’s the setup you should use:
- The Root CA should be offline, and not domain joined.
- The Subordinate CA should be online, and domain joined.
The first task we’re faced with is actually installing ADCS on both the Root and Sub CA. This is relatively easy and can be done through the server manager, under Add Roles and Features.
Additionally, if you’re not one for GUIs or your Root is running Server Core, you could use Powershell.
Anyway, time to get started on the Root CA:
Open the Server Manager, navigate to Add Roles and Features. Navigate to the Role-based or feature based installation and click next.
You’ll find a screen for “Active Directory Certificate Services” , select this and accept the popup asking you to install the management tools as well. You’ll want these for configuring AIA and CRL publication locations.
Go through all the steps, just clicking next. Ensure that when you get to “ADCS -> Role Services” that the only selection is “Certification Authority”, click next and click “Install”
Once the role is installed, there’s a couple things that need to be completed.
- Configure the Root CA, and generate a Certificate
- Configure the Root CAs maximum validity period.
- Configure Root CA AIA and CRL Publishing locations
- Last, issue a certificate for the Sub CA once we’re complete with the setup there.
You’ll probably notice in the Server Dashboard that there is that notorious yellow caution icon, let’s click that and get to configuring our certification authority.
Some things I think you can do without me showing you pictures, hopefully:
- Specify credentials, click next.
- Select Role of Certification Authority, click next.
- Select “Standalone CA”, click next.
Next up, we need to generate our private key, to do this select “Create a new private key”, and click “Next>”
So what about these crypyography options?
Honestly, that’s all on you and your business requirements. I personally prefer Elliptic Curve to RSA, so I’ll be creating my Certificates with ECC where possible, when we get to smart cards, we’ll have to deal with RSA. I’ll put an section in for my general preferences and recommendations at the end and why I make certain choices.
For my options, I’m selecting
- Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
- Key Length: 384
- Hash Algorithm: SHA384
In the Next Window, I’m only going to specify my Root CA name.
Lastly, the validity period. This is really contingent on your needs, but Root CAs can be valid as long as you feel confident in the encryption and protection mechanisms behind them.
Obviously public and government CAs have guidelines and regulations they have to follow, but for enterprise CAs, that’s really a business decision based on the risk. I recommend no longer than 15 years.
Next up we’ll specify where we want the certificate database and logs to be located. I’m going to move them from the default location to a seperate location. The default location is “C:\Windows\System32\CertLog”
Next up, just verify the options you selected and click “Configure”.
Once, you get it configured, you’ll get a message stating success, let’s move on to the next part.
Configuring Maximum Issuance Lifetime
For those of you familiar with certificate requests, you’re familiar with the fact that you usually specify the desired certificate lifetime in your request. While this might seem like it’s what actually dictates how long your certificate is valid for, it’s actually something else.
Open the registry editor and navigate to the following registry hive:
There are two registry values you may need to edit, these have to do with validity period of issued certificates.
The first one is the only one we will be editing, since the default value for the other one is already set to years.
Key Name: ValidityPeriodUnits Type: REG_DWORD Default Value: 1 We're changing it to: 10
The other one you might want to change, depending on your configuration is:
Key Name: ValidityPeriod Type: REG_SZ (String) Default Value: Years
Configuring AIA and CRL Publishing Locations
Open the Certification Authority MMC Snap-in and point it to your CA if it isn’t already.
Right click on your CA name and click “Properties”, open the “Extensions” tab.
I’m going to need to delete all the default entries for CRL Distribution Points and AIA:
Next up I’m going to want to specify the locations that these are stored locally, for this I’m publishing them to the “C:\Certificates\DB” folder.
CDP: C:\Certificates\DB\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl AIA: C:\Certificates\DB\<ServerDNSName>_<CaName><CertificateName>.crt
Next up, I’m also going to specify where they will be published on my Subordinate CA. I will have to manually import these, but they’ll be published using an IIS site on my Subordinate CA.
The location for this will be:
CDP: http://ocsp.scorchedwiremedia.net/certs/CaName><CRLNameSuffix><DeltaCRLAllowed>.crl AIA: http://ocsp.scorchedwiremedia.net/certs/<ServerDNSName>_<CaName><CertificateName>.crt
You’ll notice that I selected a few check boxes, make sure you check all of these. Some of these are just for the sake of beauty when pulling up “pkiview.msc”, the others are actually important for telling clients where to look for new CRLs.
Next up, you’ll click “Apply”, and the service will restart.
One more thing we’ll want to do before we continue is set the CRL interval for when CRLs will be published. Since the CA is offline, I’m going to set the CRL publishing interval to every 52 weeks, I’ll have to turn this on next January to publish a new CRL.
To do this, drill down to revoked certificates in and right click “Properties” and set the interval to “52 weeks”, you can also set this higher if you really want to, no need to publish delta CRLs since we won’t be online often enough.
Now, right click the “Revoked Certificates” and click “Publish CRL”, go grab the CRL from the file location on the local disk and export this to a place you’ll remember for later, we’re going to need this when setting up the Subordinate CA.
Setting up the Sub CA
Time to move on to our Sub CA Server. We’ll be going through and installing AD CS on that too, but I won’t go through the pictures on that part until we get to the configuration. The following roles should be installed on your Sub CA, which should be domain joined:
- Certification Authority
- Online Responder (we’ll use this in another part of this series, so just install it for now)
- IIS – for publishing CRLs, for now.
Optionally, you can install the Certificate Enrollment Web Service, which provides a web interface for users to enroll in and request certificates. Since I use the Certification Authority MMC Snapin, I don’t see a need for this as most times we will be enrolling on behalf of other users or users will be automatically enrolled through AD.
Now that it’s installed, the first thing I’m going to do is create an IIS site for the CRLs and Certificates. First I’m going to create the directory “C:\certs” and copy the CRL from my Root CA here then I’m going to create a virtual site for this in IIS Manager.
- <SERVER-NAME>\IIS_USRS should have read only access.
- NETWORK SERVICE should have read only access.
- Authenticated Users should have read only access.
In IIS Manager, I’m going to right click the Default Web Site and select “Add Virtual Directory”, the virtual directory name will be “certs”, pointed to the physical directory “C:\certs”
I’ve also enabled directory browsing so I can navigate to the website and validate the certs and CRLs are there:
Now, in my browser I will validate that the Root CAs CRL I placed there can be reached
Now that we’ve setup all the pre-requisites for our Subordinate CA to validate these CRLs, it’s time to configure our Sub CA:
Go back to the server manager and get rid of that pesky yellow caution icon, it’s time to configuration ADCS.
Again, somethings you can do without me:
- Enter Credentials, click next.
- Select “Certification Authority”, click next.
- Select “Enterprise CA”, click next.
- Select “Subordinate CA”, click next.
- Select “Create a new private key”, click next.
Select the cryptography for this one, I’m going to use the same I used on the Root CA:
- Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
- Key Length: 384
- Hash Algorithm: SHA384
The Common name for this CA will be “Scorched Wire Media Group Subordinate CA G1”
Click next, save the Certificate Signing Request (CSR) to the local disk, copy to a location that you will remember as well, we’ll use this to request the Certificate from the Root CA.
Click next, select where you’re going to save the certificate database to, and click configure.
Issuing our Sub CAs Certificate
Now that we’ve generated the request, lets take that and copy it to our root CA server. On the Root CA server, open up the Certification Authority MMC Snap-in.
Right click on your CA, select “All Tasks”, and “Submit New Request”
Select the CSR from your Sub CA, refresh the “Pending Requests” tab, and right click your request and select “All Tasks”, click “Issue”
Next, go to the “Issued Certificates” tab to locate your Sub CA’s certificate. Click “Open”, navigate to the certificate details and select “Copy to File”, use the certificate export wizard to export the public key and copy this to your Sub CA.
Installing the Public Key on Our Sub CA
Next go back to our Sub CA and open up the Certification Authority MMC Snap-in. You’ll notice that the services aren’t started, and that’s because we haven’t installed our certificate yet. Right click your CA Name and select “All Tasks” and click “Install CA Certificate”, in the popup, navigate to and select the certificate you exported in our previous step.
If you exported the certificate in a format that includes the Root Certificate, you should not have any issues with the CA Services starting on your Sub CA. If you get an issue saying that the certificate signature cannot be validated, this is because the Root Certificate needs to be installed in the Trusted Root Certification Authorities certificate store.
Next up, make sure you export the Root Certification Authorities Certificate in the format specified in the AIA locations. If all is done correctly, you should be able to open “pkiview.mmc” and see no errors.
You made it this far:
You made it this far, so you should know a few things that should be done moving forward:
- Cleanup CRL and AIA distribution points on the Sub CA, there’s some defaults that just need to be removed to avoid issues later.
- Since the Sub CA is an enterprise CA, all CRLs are already published to Active Directory, so no need to publish them to the IIS virtual directory unless you want to.
- Think deeply about the cryptography used. Using next-generation encryption where possible will save us all when computing power eventually get’s powerful enough to break RSA 2048-bit keys.
- If your Root CA is in a production environment and used for actual enterprise certificate services, consider full disk encryption to protect against simple methods used to steal the CAs private key.
- Consider migrating your IIS to HTTPS once your have your CA setup, if you’re like me, you encrypt everything (even DNS), because you’re paranoid.
- You’ll notice I’m using the DNS name ocsp.scorchedwiremedia.net, that’s because one of our future updates to this series will cover setting up an online responder for Smart Cards and S/MIME.
- When we modified the validity period, we didn’t actually specify the validity period of specified certificates. The validity period is actually determined as the intersection of the shortest period between the configured validity period and that on the Signing Request. Therefore, if a CSR requested a cert that would last 5 years, but the CA was only configured to issue certs for 2 years, the cert validity period would be 2 years. On the flip-side, if a CSR requested a cert that was 3 years, but the CA was configured for 5 years, the cert issued would be valid for 3 years.
- Don’t forget to update the configured validity period on your Sub CA, otherwise all your Certificate Templates will be ignored for validity periods when certificates are issued using them.
- Don’t forget to harden your CAs, you don’t want them to be breached because you forgot to do your due-diligence.
- Don’t forget to publish your CA certs to domain joined computers. The easiest way for this is just a Group Policy that publishes the Root CA to the Trusted Root Certification Authorities certificate store and the Sub CA to the Intermediate Root Certification Authorities Certificate Store.
Here’s a good table on the effective strength of ECC vs RSA: