What Is a Certificate Authority (CA)

Introduction

When you visit a banking website, your browser displays a padlock icon, ensuring your connection is securely encrypted and safe from eavesdroppers. But encryption alone only solves half the problem. If a hacker intercepts your connection and provides their own encryption key, you would have a perfectly secure, encrypted connection directly to the hacker. To prevent this, your browser needs proof that the encryption key it receives actually belongs to your bank. This is where the Certificate Authority (CA) steps in. A CA acts as the digital equivalent of a passport office. It is a highly trusted third party that verifies the identity of organizations and issues cryptographic documents — digital certificates — linking that identity to an encryption key. The entire security infrastructure of the internet, from secure web browsing to email delivery, relies entirely on the integrity of a few dozen major Certificate Authorities.

What Is a Certificate Authority?

A Certificate Authority (CA) is an organization authorized to issue, revoke, and manage digital certificates.

A digital certificate is a small electronic file that acts as a digital ID card. It contains the name of an organization or domain, its public key, an expiration date, and — most importantly — the digital signature of the CA that issued it.

When your browser connects to example.com, the server sends its digital certificate. Your browser checks the signature on the certificate. Because your browser’s operating system comes pre-installed with a list of trusted CAs, it can cryptographically verify that the certificate was genuinely issued by a recognized CA, guaranteeing you are communicating with the real example.com.

Without Certificate Authorities, the internet would operate on a “trust on first use” basis, making man-in-the-middle attacks trivial. CAs provide the foundational layer of authenticated trust required for global e-commerce and secure communication.

The Chain of Trust: Root and Intermediate CAs

Certificate Authorities do not issue certificates directly from a single master key. For security, they operate a tiered hierarchy known as a Chain of Trust.

The Root CA

At the top of the hierarchy is the Root CA. The Root CA certificate is self-signed and its public key is physically embedded into the source code of web browsers and operating systems (this is called a Root Store). The private key belonging to a Root CA is the crown jewel of internet security. Because its compromise would allow an attacker to forge certificates for any website on the internet, the Root CA private key is generated and stored on a highly secure Hardware Security Module (HSM). It is kept offline, powered down in a physical vault, and only activated in a heavily audited ceremony a few times a year.

The Intermediate CA

Because the Root CA is kept offline, it cannot respond to automated, daily requests for new certificates. Instead, the Root CA signs a certificate for an Intermediate CA. The Intermediate CA is connected to the internet and issues the actual end-user (leaf) certificates for websites and applications.

When a server presents its certificate to your browser, it also presents the Intermediate CA certificate. Your browser verifies the server’s certificate was signed by the Intermediate CA, and then verifies the Intermediate CA was signed by the Root CA. This chain allows the high-risk daily issuance operations to happen on an intermediate level; if an Intermediate CA is ever compromised, the Root CA can revoke it and issue a new one without requiring every user on earth to update their browser.

VIDEO · READY 16:9

PLAY

Certificates and Certificate Authority Explained

Types of Certificates Issued by a CA

Certificate Authorities issue different tiers of certificates based on how rigorously they verify the applicant’s identity.

Real-World Use Cases

Public HTTPS (Let’s Encrypt): Let’s Encrypt is a non-profit Certificate Authority that revolutionized internet security by providing free, automated Domain Validated (DV) certificates. By providing a protocol (ACME) that allows servers to automatically request, verify, and renew their own certificates, Let’s Encrypt eliminated the financial and administrative barriers to encryption, driving the web to near 100% HTTPS adoption.

Internal Enterprise PKI (Private CA): Large corporations often set up their own Private Certificate Authority (such as Microsoft Active Directory Certificate Services). Unlike a public CA, a private CA’s root certificate is not trusted by the global internet. Instead, the IT department uses endpoint management software to install the private Root CA onto employee laptops. This allows the company to issue certificates for internal intranet sites, employee VPN authentication, and Wi-Fi access without paying a public CA for every internal asset. For a deep dive into the architecture that supports this, see our guide on Public Key Infrastructure (PKI) Explained.

Common Mistakes to Avoid

Ignoring Certificate Revocation. If a server’s private key is stolen, the certificate must be immediately revoked by the CA so browsers stop trusting it. Historically, CAs published a Certificate Revocation List (CRL). Modern systems use OCSP (Online Certificate Status Protocol) or OCSP Stapling to check validity in real time. Failing to implement revocation checks allows attackers to use stolen certificates to impersonate secure sites. Read How Certificate Revocation Works (CRL vs OCSP) for details on implementation.

Trusting Unverified Private CAs. A common security failure occurs when developers bypass certificate warnings in testing environments by telling their operating system to permanently trust a self-signed development CA. If a malicious actor gains access to that development CA’s private key, they can intercept all of the developer’s web traffic undetected. Development Root CAs must be closely guarded or restricted in scope.

Getting Started

Securing your infrastructure with a Certificate Authority is simpler than ever thanks to automation.

First, for public-facing websites and APIs, utilize an automated CA like Let’s Encrypt. Install a client like Certbot on your server. Certbot will automatically negotiate with the CA to verify you control the domain, download the certificate, and configure your web server (like Nginx or Apache) to use it. Furthermore, it sets up an automatic scheduled task to renew the certificate before its 90-day expiration.

Second, for internal corporate services, determine if you need a Private CA. Cloud providers offer managed private CA services (like AWS Private CA or Google Cloud CAS) that handle the complex offline-root security for you, allowing you to easily issue certificates for internal microservices and employee devices.

Finally, implement monitoring. A certificate expiration will take your website offline instantly, causing a major outage. Use external monitoring tools to alert your team 30 days before any certificate expires. To understand the underlying encryption protocol that utilizes these certificates to secure the connection, read our article on TLS Handshake Explained.