A PKI hierarchy can have one or more tiers. In a single tier PKI environment your only CA server will be the Root CA. If you have more tiers your Root CA will issue subordinate CA certificates CA servers below the root. If you have a two tier PKI setup you don’t need to have access to your Root CA server on a day to day basis. Since your users can request certificates from the subordinate CA the Root CA can be offline. Obviously having your Root CA offline increases the security of your PKI environment since no one has network access to the server. How many tiers your setup will use depends of what you want to do with the PKI environment, your security requirements and the trust you put into the environment.
Think of the Root CA as the King when you play Chess. If the king is lost you lose, you remove the rest of the pieces from the board and setup another game if you want to play again. When reading about PKI, some texts tell you that the Root CA should be hidden away in some bunker with two armed guards. Most of the places where I’ve worked hasn’t had two guards to spare. If you’re short on guards a comforting thought is, if we make the comparison with chess again, some games are more important than others. Likewise some PKI environments will require better protection than others.
When you create a Root CA certificate, the Root CA will sign its own certificate. At this point the new root CA certificate won’t be trusted by anyone. Before the certificates within the new PKI environment can be used the Root CA certificate has to be distributed to the devices which will validate certificates within the environment. If you are going to use this within a Windows network you can distribute the Root CA certificate by publishing it to Active Directory. If your PKI environment will be used by other companies you will have to sent them the Root CA certificate and tell them to trust it. If you will use the PKI environment on your routers and switches you will have to install the Root CA certificate on all those devices.
When a CA is compromised you should revoke all the certificates that the CA has issued along with certificates issued by subordinate CA servers. The difference if the Root CA server is compromised compared to a subordinate CA is that when the Root CA is compromised you will have to distribute the CA certificate again. If the PKI environment is used outside of your organization, for example at a partner company, that party will also have to trust a new Root CA. The partner company will also have to distribute the root CA certificate to its devices.
In order to save yourself the trouble of having to redistribute the Root CA certificate, you can disconnect your Root CA and have it locked away until you need it. Instead your users will request their certificates from a subordinate CA. If the subordinate CA is compromised you will still have to revoke that CA and all certificates it has issued. At that point when you create a new sub CA, since your users already trust your Root CA it will also trust the new CA because of the certificate chaining process.
Aside from the redistribution of the Root CA certificate, there are other reasons why you might want to use a subordinate CA. This could be administrative purposes where you have one offline Root CA, and one subordinate CA in Europe and one in USA. You could have different subordinate CAs because you want to have different CRL validity periods. For example if you have one CA which issues certificates which users use to login to your network such as smart card login certificates, you might want the CRL to expire just after a short time so you can lock out a user who has lost their smart card. This however doesn’t mean that you want to use a CRL with a short lifetime on all your certificates, so you can use a different CA for your other certificates.
Most PKI setups will have one, two or three tiers. With one tier you only have your Root CA which is responsible for issuing and revoking all the certificates. In a two tier environment you will have an offline Root CA and one or more subordinate CA servers. In a three tier environment you would have an offline Root CA, one or more subordinate policy CAs which can also be offline. These policy CAs will govern the policy of the subordinate CAs below them, the issuing CA servers.
In a three tier environment the end users’ certificates will be signed by an issuing CA. The issuing CA certificates will be signed by the policy CA. The policy CA certificate, or certificates if you have several policy CAs, will be signed by the Root CA. As usual the Root CA certificate will be signed by itself.
On the image to the right you can see that the current certificate for www.amazon.com is part of a two tier PKI, where the web server certificate is signed by the subordinate CA “VeriSign Class 3 Secure Server CA - G2”. The subordinate CA is signed by the Root CA named “VeriSign”. Since the VeriSign Root CA came preloaded on my computer I can visit https://www.amazon.com without receiving a warning. This is because the certificate for www.amazon.com “chains” to a trusted Root CA.
You can also come across PKI environments with four tiers, though it is more unusual. There isn’t a right or wrong answer as to how many tiers you should use. It is however important that you plan things out and design your environment before you start installing and issuing certificates.
This post is part of the Getting Started with Public Key Infrastructure series.