Organizations typically decide to install a PKI because they want a piece of software which requires it. Usually, the end result is someone RDP’ing to a domain controller, starting server manager, installing the ADCS role, and clicking next a few times. This can lead to problems down the road. To understand this more, first we need to go over a bit of certificate basics.
Let’s pretend I have a CA named ‘MyCA.fakecompany.com’ and I issue a web server certificate from it to ‘MyWebServer.fakecompany.com’. When a client visits the website ‘mywebserver.fakecompany.com’ using https, the web server presents it’s certificate to our browser. This certificate must be ‘validated’ according to multiple criteria: expiration, revocation, and trusted root. Expiration is easy — certificates contain a date range for which they’re valid. The computer validating the certificate can check it’s current date and time against the certificate’s date range, and validate that criteria. Revocation and Trusted Root are a bit more tricky.
Certificates are considered ‘valid’ when they meet the following criteria:
- The certificate is not expired.
- The certificate has not been revoked.
- The computer validating the certificate trusts one of the CA’s in the chain.
As stated before, expiration is easy to validate. But what about revocation?
Let’s say that the certificate I issued to MyWebServer is valid for 1 year, but a hacker broke in and stole the certificate’s private key about a month into that 1 year validity period. The hacker can use this certificate in combination with a DNS redirection exploit on a client PC to act as my web server, and no one would be the wiser.
If we wanted to stop the hacker from using our web server’s certificate to spoof our service (say, http://www.myimportantbankinginfo.com), then we need a mechanism to tell the browser not to use the certificate. This mechanism is called certificate revocation.
To revoke a certificate in Server 2008, you run the ‘certification authority’ snap-in, right-click a certificate, and choose ‘revoke’. But what happens behind the scenes? How does the client web browser find out about the certificate’s revocation status?
Certificate Authorities maintain a list of revoked certificates that other systems can download and check. This list is called the CRL, or certificate revocation list. Anytime a browser accesses an https website, the browser finds and downloads the CRL corresponding to the CA which issued the web site’s https certificate. It then checks to see if the certificate presented by the web server is listed in the CRL. If so, the certificate will not be validated and you’ll see the browser’s certificate warning page.
But where does the browser find the CRL? Good question. Certificates can include an extension called a ‘CDP’, also known as a ‘CRL Distribution Point’. This is a list of HTTP or LDAP URL’s which point to the CRL for the certificate’s parent CA. You can even check the CRL of this web page right now! On your browser, click the ‘lock’ icon next to the URL at the top of the page and choose ‘certificate information’. After poking around, you should be able to find a line named ‘CRL Distribution Point’. If you copy the URL and paste it into the web browser, you will get a file ending in .crl containing a list of serial numbers of certificates that the CA has ‘revoked’.
An interesting note is that CRL’s expire. If the CDP presents your browser with an expired CRL, the certificate won’t validate unless a secondary CDP point contains a valid CRL.
Next, let’s talk about the chain of trust.
Trusted Roots and the AIA Extension
OK, so let’s pretend we have a certificate which hasn’t expired, and is not listed in the CRL’s. What we now know is that at some point in time someone decided to issue a certificate and hasn’t decided to revoke it. Now, we want to know if the issuer of the certificate is someone we trust. I can issue certificates for amazon all day, but unless your computer trusts me as an authoritative source, my certificates won’t validate.
So for this imaginary certificate we have, let’s also say that it’s issuing CA is named ‘Contoso Issuing CA’. If we look in the ‘trusted root certificate authorities’ store on our computer, we don’t see an entry for ‘Contoso Issuing CA’, so the certificate doesn’t immediately validate. This doesn’t mean we’re done though.
It’s not important that the direct parent of the certificate be trusted by your client, it’s just important that someone on the chain of trust is trusted by your client. For example, the grandparent, or the great-grandparent, or the great-great…ok, I think you get it.
So where do we find our certificate’s parent CA, let alone the grand-parent? From the AIA extension of course! AIA stands for ‘Authority Information Access’. It’s a HTTP or LDAP URL that points to the download location of the CA Certificate of the issuing parent of the current certificate you’re looking at. You can check this out in the current browser session by clicking the ‘lock’ on the address bar of any https website, choosing ‘certificate information’, and poking around for a line that reads ‘AIA Location’.
So, we follow the AIA of our certificate, and we get the ‘CA Certificate’ of the ‘Contoso Issuing CA’. This certificate has it’s own CRL to check, expiration date, etc. It checks out, but our computer doesn’t trust this CA, so we follow the AIA url and download the CA cert of the parent of ‘Contoso Issuing CA’. Let’s say that we get back a certificate from GoDaddy (or Equifax, or a bunch of other operators). Our computer trusts those, so the certificate validates.
Whew — simple right?
So what does this have to do with building a 1-Tier vs 2-Tier PKI?
PKI in Tears
With a single-tier PKI, in order for clients to trust your certificates, you need to install the CA Certificate of the CA into the trusted root certificate authorities store on all your clients. This is easy enough to do via group policy. Also, by default, the CDP and AIA locations on a Microsoft CA will point to LDAP locations in active directory, which the CA will manage automatically. Sounds awesome, right?
Problem 1 – Internet Clients
But what if your client isn’t connected to the LAN? Now you can’t get to LDAP, and so your certificates all fail to validate for laptop clients. If we’re just talking about enabling LDAPS on domain controllers than this isn’t a big deal, but for multi-platform web servies or SCCM Native\Internet mode, it’s a deal killer.
I can hear your guys now — “But John, what if we install a 1-Tier PKI with HTTP AIA and CDP locations? Hah! We got you now!”
Problem 2 – Recovering from a CA Hack
But what if your CA is compromised? The only way to recover and invalidate certificates with a single-tier PKI would be to visit every client and remove the old CA’s certificate from the trusted root certificate authorities share. Read that again — you need to visit _every client_ that you want to recover. If you miss a client, then that client is completely vulnerable to the attacker and will remain so until the CA certificate has expired.
How is this different from a multi-tier PKI? If an online issuing CA is compromised in a multi-tier PKI, all we need to do is revoke that specific compromised CA, publish a new CRL to the CDP locations, and re-issue the client certificates. This can all be done with a couple of clicks, and we’re good to go.
Even Better – Use an Offline Root
Having multiple tiers is helpful, but what if the root gets compromised? Then you’re in the same boat as a single-tier PKI — hitting every client to uninstall the compromised CA certificate.
The best-practice here is to create a ‘Standalone Offline Root CA’. This server would be kept powered off and disconnected from the network. It should only be powered on when it’s necessary to authorize other CA’s and publish CRL’s. Even then, these functions should be handled via sneaker-net. It should not be connected to the network. This will provide a greater level of protection for the root CA of your PKI.
Additionally, it’s possible to buy a hardware security module to store the root keys, so that an attacker would need to compromise both the offline root CA and the HSM.
And that’s it! 90% background information, 10% why a 1-tier PKI is not optimal. This stuff is hard and I glossed over a lot of the details (certificate hash checking, security policies, etc). For a more in-depth treatise on certificate validation, see the references below. Also, when dealing with Microsoft PKI, the gold-standard is still Brian Komar’s book. It’s awesome, but you might have trouble finding it. I got mine from eBay, but Safari Tech has it, and I think there are digital copies available for the kindle.