en English

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

What Is a Certificate Authority (CA)?

What is a CA?

What Is a Certificate Authority (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.

Need a certificate? SSL.com has you covered. Compare options here to find the right choice for you, from S/MIME and code signing certificates and more.


How does a certificate authority validate a certificate?

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.

What is 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:

end-entity certificate

What is a trust anchor?

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):

trust anchor

What is an intermediate certificate?

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:

intermediate certificate

What is an end-entity certificate?

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:

end-entity certificate

Why does a chain of trust matter?

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.


Note: Although any organization, such as a company department or a government agency, can operate a CA, commercial CAs like SSL.com can provide publicly trusted certificates for  purposes such as HTTPS websites, S/MIME email, and code and document signing, without the hassle of having to maintain public trust and an audited PKI. SSL.com provides hosted PKI with public or private trust for both business and government customers.
Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.



Related FAQs

Follow Us

What is SSL/TLS?

Play Video

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com