What is a CA?
A certificate authority (CA), also sometimes referred to as a certification authority, is a company or organization that acts to validate the identities of entities (such as websites, email addresses, companies, or individual persons) and bind them to cryptographic keys through the issuance of electronic documents known as digital certificates.
A digital certificate provides:
Authentication, by serving as a credential to validate the identity of the entity that it is issued to.
Encryption, for secure communication over insecure networks such as the Internet.
Integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.
Typically, an applicant for a digital certificate will generate a key pair consisting of a private key and a public key, along with a certificate signing request (CSR). A CSR is an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.). Key pair and CSR generation are usually done on the server or workstation where the certificate will be installed, and the type of information included in the CSR varies depending on the validation level and intended use of the certificate. Unlike the public key, the applicant’s private key is kept secure and should never be shown to the CA (or anyone else).
After generating the CSR, the applicant sends it to a CA, who independently verifies that the information it contains is correct and, if so, digitally signs the certificate with an issuing private key and sends it to the applicant.
When the signed certificate is presented to a third party (such as when that person accesses the certificate-holder’s website), the recipient can cryptographically confirm the CA’s digital signature via the CA’s public key. Additionally, the recipient can use the certificate to confirm that signed content was sent by someone in possession of the corresponding private key, and that the information has not been altered since it was signed. A key part of this aspect of the certificate is something called a chain of trust.
In SSL/TLS, S/MIME, code signing, and other applications of X.509 certificates, a hierarchy of certificates is used to verify the validity of a certificate’s issuer. This hierarchy is known as a chain of trust. In a chain of trust, certificates are issued and signed by certificates that live higher up in the hierarchy.
A chain of trust consists of several parts:
1. A trust anchor, which is the originating certificate authority (CA).
2. At least one intermediate certificate, serving as “insulation” between the CA and the end-entity certificate.
3. The end-entity certificate, which is used to validate the identity of an entity such as a website, business, or person.
It’s easy to see a chain of trust for yourself by inspecting an HTTPS website’s certificate. When you check an SSL/TLS certificate in a web browser, you’ll find a breakdown of that digital certificate’s chain of trust, including the trust anchor, any intermediate certificates, and the end-entity certificate. These various points of verification are backed up by the validity of the previous layer or “link,” going back to the trust anchor.
The example below shows the chain of trust from SSL.com’s website, leading from the end-entity website certificate back to the root CA, via one intermediate certificate:
The root certificate authority (CA) serves as the trust anchor in a chain of trust. The validity of this trust anchor is vital to the integrity of the chain as a whole. If the CA is publicly trusted (like SSL.com), the root CA certificates are included by major software companies in their browser and operating system software. This inclusion ensures that certificates in a chain of trust leading back to any of the CA’s root certificates will be trusted by the software.
Below, you can see the trust anchor from SSL.com’s website (SSL.com EV Root Certification Authority RSA R2):
The root CA or trust anchor has the ability to sign and issue intermediate certificates. Intermediate certificates (also known as intermediate, subordinate, or issuing CAs) provide a flexible structure for conferring the validity of the trust anchor to additional intermediate and end-entity certificates in the chain. In this sense, intermediate certificates serve an administrative function; each intermediate can be used for a specific purpose — such as issuing SSL/TLS or code signing certificates — and can even be used to confer the root CA’s trust to other organizations.
Intermediate certificates also provide a buffer between the end-entity certificate and the root CA, protecting the private root key from compromise. For publicly trusted CAs (including SSL.com), the CA/Browser forum’s Baseline Requirements actually prohibit issuing end-entity certificates directly from the root CA, which must be kept securely offline. This means that any publicly trusted certificate’s chain of trust will include at least one intermediate certificate.
In the example shown below, SSL.com EV SSL Intermediate CA RSA R3 is the sole intermediate certificate in the SSL.com website’s chain of trust. As the certificate’s name suggests, it is only used for issuing EV SSL/TLS certificates:
The end-entity certificate is the final link in the chain of trust. The end-entity certificate (sometimes known as a leaf certificate or subscriber certificate), serves to confer the root CA’s trust, via any intermediates in the chain, to an entity such as a website, company, government, or individual person.
An end-entity certificate differs from a trust anchor or intermediate certificate in that it cannot issue additional certificates. It is, in a sense, the final link as far as the chain is concerned. The example below shows the end-entity SSL/TLS certificate from SSL.com’s website:
A chain of trust ensures security, scalability, and standards compliance for CAs. It also ensures privacy, trust, and security for those who rely upon end-entity certificates, such as website operators and users.
It is important for website owners and other users of end-entity certificates to understand that a complete chain of trust is necessary for their certificate to confer a CA’s trust successfully. For information on diagnosing and troubleshooting browser errors resulting from an incomplete chain of trust, please see our article on installing intermediate certificates and guide to browser error messages.
