What Is a Certificate Authority (CA)?

A certificate authority (CA) is an organization that issues digital certificates used to verify the identity of websites, organizations, and individuals on the internet. When your browser shows a padlock icon for an HTTPS website, it has verified that the site's SSL certificate was issued by a trusted CA. Without certificate authorities, there would be no way to confirm that you are communicating with the real website and not an impersonator.

CAs are the foundation of internet trust. Every HTTPS connection depends on a chain of trust that starts with a CA. This guide explains how CAs work, the different types, who the major CAs are, and what happens when the system fails. For the certificate itself, see What Is an SSL Certificate?.

How Certificate Authorities Work

The CA system works through a hierarchy of trust anchored to root certificates that are pre-installed in browsers and operating systems.

The Trust Model

1. Root CAs are at the top of the hierarchy. Their root certificates are embedded in your browser and operating system's trust store. These root certificates are the trust anchors. If your browser trusts a root certificate, it trusts any certificate signed by that root (or by intermediates signed by that root).

2. Intermediate CAs sit between root CAs and the certificates issued to websites. Root CAs sign intermediate certificates, and intermediate CAs sign end-entity certificates. This layering protects the root key: if an intermediate is compromised, only that intermediate needs to be revoked, not the root.

3. End-entity certificates are the SSL certificates installed on websites. They are signed by an intermediate CA, which is signed by a root CA. This creates the certificate chain that your browser verifies.

The Issuance Process

When you request an SSL certificate, the CA must verify that you control the domain before issuing the certificate. The verification process depends on the certificate type:

Domain Validation (DV): The CA verifies domain control through one of several automated methods: placing a specific file on the web server, adding a DNS record, or responding to an email sent to an address at the domain. DV certificates can be issued in minutes.

Organization Validation (OV): In addition to domain control, the CA verifies the organization's legal existence, physical address, and the requester's authority to request the certificate. OV validation takes one to three business days.

Extended Validation (EV): The CA performs the most thorough verification, including legal entity verification, operational existence, physical address confirmation, and verification that the requester is authorized by the organization. EV validation can take one to two weeks.

For all validation levels, the encryption is identical. The difference is in how much the CA verified about the certificate requester before issuing it. See Types of SSL Certificates.

Major Certificate Authorities

The SSL certificate market is dominated by a handful of CAs:

Let's Encrypt is a free, automated, open CA operated by the Internet Security Research Group (ISRG). It issues only DV certificates and has become the largest CA by volume, with certificates on hundreds of millions of websites. Its mission is to make HTTPS ubiquitous by removing cost and complexity barriers.

DigiCert is a commercial CA that offers DV, OV, and EV certificates. It acquired Symantec's certificate business in 2017 and is one of the most widely used commercial CAs, particularly for enterprise customers.

Sectigo (formerly Comodo CA) is one of the largest commercial CAs by certificate volume. It offers the full range of certificate types and is popular with hosting providers and resellers.

GlobalSign is a European CA that serves enterprise customers and offers DV, OV, and EV certificates. It is owned by GMO Internet Group.

GoDaddy issues SSL certificates through its registrar and hosting platform. It is a common choice for small business customers who already use GoDaddy for domain registration.

Google Trust Services operates as a CA issuing certificates for Google's own services and for customers through Google Cloud.

Amazon Trust Services issues certificates through AWS Certificate Manager (ACM) for use with AWS services like CloudFront, Elastic Load Balancing, and API Gateway.

Root Certificate Programs

For a CA's certificates to be trusted by browsers, the CA must be included in the root certificate programs maintained by browser and OS vendors:

• Mozilla Root Store: Used by Firefox and many Linux distributions.
• Apple Root Certificate Program: Used by Safari, iOS, and macOS.
• Microsoft Trusted Root Certificate Program: Used by Edge, Chrome on Windows, and Windows.
• Google Chrome Root Store: Chrome is transitioning to its own root store.

Inclusion in these programs requires CAs to undergo audits (typically WebTrust or ETSI audits), comply with the CA/Browser Forum Baseline Requirements, and maintain strict security practices. CAs that fail to meet these standards can be removed from root programs, effectively revoking trust in all their certificates.

Certificate Transparency

Certificate Transparency (CT) is a system that requires CAs to publicly log every certificate they issue. These logs are append-only and publicly auditable. Anyone can search the logs to see what certificates have been issued for a domain.

CT was created in response to incidents where CAs issued unauthorized certificates (either through compromise or mismanagement). With CT, domain owners can monitor the logs and detect any certificate issued for their domain that they did not request.

All major CAs are required to submit certificates to CT logs as a condition of browser trust. Chrome requires CT for all publicly trusted certificates.

For more on this system, see Certificate Transparency.

When CAs Fail

The CA system depends on CAs behaving correctly. When they do not, the consequences are severe.

Notable Incidents

DigiNotar (2011): A Dutch CA was compromised by attackers who issued fraudulent certificates for Google, Yahoo, Mozilla, and other major domains. The certificates were used to intercept Iranian citizens' communications. DigiNotar was removed from all browser trust stores and went bankrupt.

Symantec (2015-2017): Google discovered that Symantec had issued thousands of certificates without proper validation, including test certificates for domains they did not control. After a prolonged dispute, Google distrust Symantec's certificates, forcing a transition to DigiCert.

Let's Encrypt Revocation (2020): A bug in Let's Encrypt's CAA checking code meant some certificates were issued without proper CAA verification. Let's Encrypt had to revoke approximately 3 million certificates, causing widespread disruption.

How Browsers Respond

When a CA is found to be untrustworthy, browser vendors can:

• Distrust the CA entirely. Remove the root certificate from the trust store. All certificates issued by that CA immediately become untrusted.
• Partial distrust. Distrust certificates issued after a specific date or for specific domains.
• Require Certificate Transparency. Require all certificates from the CA to be logged before being trusted.

These actions protect users but cause significant disruption for websites that relied on the distrusted CA's certificates.

Self-Signed Certificates vs CA-Issued Certificates

A self-signed certificate is created and signed by the server operator rather than by a CA. Browsers do not trust self-signed certificates by default because there is no third-party verification. Visitors see a security warning that they must manually bypass.

Self-signed certificates provide encryption but not authentication. They are appropriate for development environments, internal tools, and testing. They are not appropriate for public-facing websites. See Self-Signed Certificates.

The Future of CAs

Several developments are shaping the future of the CA ecosystem:

Shorter certificate lifetimes. The industry is moving toward shorter validity periods. The maximum was reduced from 5 years to 2 years in 2018, then to 398 days in 2020. Apple proposed 45-day certificates, and the CA/Browser Forum has approved a gradual reduction. Shorter lifetimes reduce the window of exposure if a certificate is compromised but require better automation.

Automated certificate management. The ACME protocol (developed for Let's Encrypt) automates the entire certificate lifecycle: issuance, installation, and renewal. This makes short-lived certificates practical and reduces the human error that causes expiration outages.

Post-quantum cryptography. Quantum computers may eventually break the cryptographic algorithms used in current certificates. The industry is preparing by developing and standardizing post-quantum algorithms for use in certificates and TLS.

Choosing a Certificate Authority

For most websites, the choice comes down to:

• Let's Encrypt if you want free, automated DV certificates and your hosting provider supports it.
• A commercial CA if you need OV or EV validation, dedicated support, or a warranty.
• Your cloud provider's CA (ACM, Google Trust Services) if you are using their services and want seamless integration.

For a comparison of CAs and their offerings, see SSL Certificate Providers Compared.

References

1. CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," https://cabforum.org/baseline-requirements/
2. RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," May 2008. https://datatracker.ietf.org/doc/html/rfc5280
3. Google, "Certificate Transparency," https://certificate.transparency.dev/
4. Mozilla, "CA Certificate Program," https://wiki.mozilla.org/CA