There are many different kinds of certificate authorities available. A description from Windows 2000 Server documentation helps to clarify. The different players are:
- Root CA
- Subordinate CA
- Intermediate CA
- Issuing CA
The CA hierarchies are very flexible based on simple rules.
The root CA is always at the top. It has a public/private key pair with the public key living in the public certificate signed by itself. It is perhaps a bit vain but it has no equal in the line of trust. It is the CA that is actually trusted by the client and server resources. The root CA needs to be protected as much as possible in the owner organisation. It is okay to have multiple CAs in a single organisation but this implies that every trusting element needs to be updated with more root CAs.
CAs can be a child of a root CA. These are known as subordinate CAs. The subordinate CA’s certificate is signed by the root CA. There are two kinds of subordinate CAs. Intermediate CAs are responsible for verifying subordinate CAs. Issuing CAs are meant to provide certificates to end uses. An issuing CA would never provide support to a child CA (since it is not allowed). Also, an intermediate would never provide certificates except for other CAs.
The trust for certificates is chained back to the root CA. A certificate path can be constructed from the knowledge gained from the CA certificates. It is much like a linked list in nature. Given the end-user certificate, the CAs can be walked back to the root CA.
For Windows, trust is gained by having the root CA certificate in the “Trusted Root Certification Authorities” store.
Based on documentation, if Windows trusts an intermediate CA, it will add it to the Intermediate Certificate Store.
Windows (at least in Windows 2000) trusts certificates based on this flow:
Reasons for validation failing:
- Dates are invalid or expired
- Certificate not in correct format
- Certificate fields might be invalid or missing
- Thumbprint or signature do not match reality
- Cert has been revoked
- Root CA is not in the trust root certificate store
Interestingly, if a CA certificate in the path is expired, it can still be possible for the certificate at the bottom to be valid. The key is that the CA certificate was valid when the bottom certificate was issued. This is a strange twist but makes sense given the alignment of dates would be very complex otherwise.
These ideas are coming from a Microsoft point of view and might not match the rest of the world. Also, the main source used was from Windows 2000 which is not the latest version. So far, this was the most straight forward reference.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 