A certificate authority (CA) is a trusted entity that issues digital certificates to authenticate content sent from web servers. These certificates are data files used to cryptographically link an entity with a public key. Web browsers use them to authenticate content sent from web servers, ensuring trust in content delivered online and facilitating more trustworthy online transactions.
What is the purpose of a certificate authority?
The main goal of a CA is to verify the authenticity and trustworthiness of a website, domain and organization so users know exactly who they’re communicating with online and whether that entity can be trusted with their data. When a CA issues a digital certificate for a website, company, or individual, it validates the entity’s identity. The certificate also binds the entity to cryptographic keys that prove that particular entity’s identity, establishes them as trustworthy, and allows them to engage in encrypted and secure communications with other entities.
When users access a website that has been issued a digital certificate, they know they are connected with an official, genuine website, not a fake or spoofed website a hacker created to steal their information or money. As providers of these certificates, CAs are a reliable, critical trust anchor of the internet’s public key infrastructure (PKI). They help secure the internet for organizations and users.
Key roles of a certificate authority
As an integral part of PKI, a CA plays multiple crucial roles:
- Issues digital certificates.
- Helps establish trust between communicating entities over the internet.
- Verifies domain names and organizations to validate their identities.
- Maintains certificate revocation lists.
Both public and private CAs can play one or more of these roles. A public CA provides its services to the public, allowing users to securely access websites and confidently engage in sensitive transactions (e.g., on banks or e-commerce websites). All major web browsers trust public CAs, which are crucial to open internet security. All public CAs charge a small fee to complete the verification process and issue a digital certificate.
Private CAs, also known as local CAs, issue digital certificates, albeit not for websites on the open web but for internal or restricted application use cases, such as virtual private networks (VPNs) and code signing.
Certificate authority examples
Numerous CAs operate worldwide and enjoy a position of trust on the internet and its PKI. Some of the most well-known CAs include:
- DigiCert. DigCert provides two types of Transport Security Layer/Secure Socket Layer (TSL/SSL) certificates for single and multiple domains: Organization Validation (OV) and Extended Validation (EV), and document signing certificates, code signing certificates, S/MIME email certificates, and mark certificates.
- RapidSSL. It provides entry-level and low-cost SSL certificates with strong 128- or 256-bit encryption for blogs, low-traffic sites and internal testing domains.
- GeoTrust. It provides a wide range of digital certificates, including OV, EV, multi-domain and wildcard SSL certificates.
- Symantec. Symantec offers a wide range of SSL certificates for securing single and multiple domains, code signing certificates to secure code and apps, and S/MIME certificates for email encryption and signing.
- Entrust. Entrust provides a certificate services platform to deploy, purchase, reissue, audit, and manage OV SSL certificates, multidomain EV SSL certificates, wildcard SSL certificates, and private SSL certificates.
How a certificate authority issues a digital certificate
The digital certificate issuance process follows specific steps:
- An applicant requests a digital certificate from a CA. First, the entity generates a cryptographic key pair, which consists of the following:
- A private key. The applicant always keeps a private key secret and it should never be shown to anyone, including the CA
- A public key. This enables encryption and is mentioned in the digital certificate the CA issues.
- In addition to the keys, the applicant also generates a certificate signing request (CSR), an encoded text file that specifies the information to be included in the certificate, such as the following:
- Public key.
- Entity’s domain name.
- Additional or alternative domain names, including subdomains.
- Organization.
- Contact details (e.g., email address).
The information included in the CSR depends on the certificate’s intended use and validation level. Steps 1 and 2 usually occur on the server or workstation where the certificate is to be installed.
- The applicant sends the CSR to the CA, which verifies the information contained in it along with the applicant’s identity. The rigorousness of the validation process depends on the type of certificate applied for.
- After successful validation, the CA generates a digital certificate.
- The CA digitally signs the certificate with its own private key to confirm that the entity’s identity has been validated.
- The CA sends the certificate to the applicant.
At this point, this digital certificate can be authenticated — by a web browser, for example — using the CA’s public key. The browser can also use the certificate to confirm that the digitally signed content was sent by a legitimate entity that holds the corresponding private key and that this information has not been altered since it was signed by that entity.
Certificate authorities vs. registration authorities
CAs often accept requests from applicants directly. Sometimes, they delegate the task of authenticating applicants to registration authorities (RAs). RAs are not authorized to issue certificates. However, they can collect and authenticate digital certificate requests from applicants. Furthermore, as trusted agents of a CA, RAs can submit those requests to the CA, which then issues the certificate to be passed through the RA to the applicant.
CAs might also use RAs for marketing and to provide customer support to applicants. The CA is required to limit the RA to registering certificates within the domain namespace assigned to the RA.
Besides RAs, CAs might also work with one or more Delegate Registration Authorities (DRA). A DRA can authenticate, validate, and even revoke digital certificates on behalf of a CA. They provide valuable support during the certificate issuance process. However, the CA has the final responsibility for ensuring the integrity of the process and maintaining digital trust in the PKI.
How a digital certificate works
A digital certificate primarily acts as a credential to validate the identity of the entity it is issued to. It also encrypts and secures communication over the internet and maintains the integrity of documents signed with it, ensuring third parties cannot alter the documents while they are in transit.
A digital certificate contains information about the entity to which it has been issued. Typically, that includes its name, contact information, organization, domain name, public key, certificate issue and expiry date, and more. The name of the issuing CA and its digital signature are also normally included in the digital certificate.
In the digital certificate, the digital signature proves that a trusted CA issued the certificate, and it was not modified by any other party.
How SSL/TLS certificates work
SSL/TLS certificates authenticate and secure websites and facilitate secure, encrypted connections. They let users know they are visiting a genuine website by displaying a padlock icon in the web browser. As important components of PKI, SSL/TLS certificates require a digital certificate to work. This is where the CA comes in.
SSL certificates are sometimes called SSL/TLS certificates or simply TLS certificates. TLS is an upgraded version of SSL.
The TLS protocol uses SSL certificates to encrypt and authenticate data streams for Hypertext Transfer Protocol Secure (HTTPS). The SSL cryptographic protocol facilitates secure encrypted connections over the internet via web browsers that connect to websites. SSL works on top of HTTP to create an HTTPS connection.
Similarly to SSL, HTTP is layered on top of TLS to create HTTPS. It encrypts otherwise readable data to provide enhanced protection for applications and websites requiring higher privacy and security, such as those involving banking, taxation and e-commerce. TLS also provides privacy between the endpoints of a data transmission and boosts data integrity so private data is extremely difficult to intercept or hack.
When a web browser initiates a secure connection over HTTPS, the SSL/TLS digital certificate is sent to the web browser. The browser checks the information in the certificate and authenticates it against its own root certificate store. This is how the certificate ensures secure, encrypted connections between a user’s browser and the organization’s web server or a website’s web server.
When this feature is working, users don’t see warning messages in their browser, such as “not sure” or “your connection is not private.” Those are displayed for insecure websites.
All major browsers, including those provided by Microsoft (Internet Explorer, Edge), Google (Chrome), Apple (Safari) and Mozilla (Firefox), all maintain their own web browser root certificate stores. This is where they post the root certificates of CAs the publishers have decided their browsers will trust.
Root certificates and intermediate certificates
The CA plays a vital role in the chain of trust, a hierarchical trust model that consists of root certificates, intermediate certificates and SSL certificates. Its activities start with a root certificate, which is used as the ultimate basis for trust in all certificates the authority issues.
The root certificate — along with the private key associated with that certificate — is treated with the highest level of security and is usually stored offline in a protected facility. It might also be stored on a device that is unpowered except when the certificate is needed.
The CA will use that root certificate to create intermediate certificates (i.e., the certificates used to sign the digital certificates the authority issues). The root certificate should never be used directly to sign digital certificates. Different intermediate certificates support different purposes. This enables the public to trust the issued certificates while protecting the root when an intermediate certificate expires or is revoked. RAs may also issue digital certificates using intermediate certificates.
Types of digital certificates
CAs don’t just issue SSL/TLS certificates. They can also issue other types of certificates for different use cases:
- Code-signing certificates. This is a way for software publishers and developers to sign their software distributions. With code-signing certificates, end users can then authenticate and validate software downloads from the vendor or developer.
- Email signing certificates. These certificates let entities sign, encrypt and authenticate email using the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol for secure email attachments.
- Object signing certificates. They accommodate signing and authenticating any type of software object.
- User/client signing certificates. Also known as signature verification certificates, they help individuals handle various authentication needs.
What is the CA/Browser Forum?
The CA/Browser Forum is a group of CAs and digital certificate consumers. It maintains guidelines for all aspects of creating, distributing and using digital certificates, including policies for certificate expiration and revocation. It also publishes baseline requirements for issuing and managing TLS certificates, code-signing certificates, and S/MIME certificates.
All active participants of the CA/Browser Forum must agree with its Intellectual Property Rights (IPR) policy and comply with all the forum’s bylaws, including its code of conduct and antitrust laws and regulations.
All CA members are subject to approved independent third-party audits. The audited CA must obtain an audit report from the auditor and provide it to the Forum. The intent is to increase trust in the PKI system and related technology.
Any infractions of these rules can prompt more audits and other consequences that could damage the CA’s reputation and lower trust in its operations and reliability.
Safeguarding the authenticity of online communications is essential to running a business. Learn how to use public and private keys in digital signatures to manage electronic documents. Also, explore types of PKI certificates and their use cases.
