What Is a Certificate Authority (CA)?

A certificate authority (CA) is a trusted entity that verifies identities and issues the digital certificates that bind a public key to a person, server, or workload. When your browser trusts a website, it is trusting the certificate authority that signed that site’s certificate. CAs are the anchor of trust behind HTTPS, code signing, and certificate-based identity.

Read on for what a certificate authority is, what a CA does and how it works, root versus intermediate CAs and the certificate types they issue, and why running your own CA has become the way teams issue infrastructure identity.

Understanding certificate authorities

A certificate authority is an organization or system trusted to confirm that a public key really belongs to the identity that claims it. The CA does this by issuing a digital certificate, which is a signed statement tying a public key to a verified name, whether that name is a domain, a company, a device, or a workload. Because the certificate carries the CA’s signature, anyone can check that it came from the CA and was not altered. 

A certificate authority is one part of a larger system called public key infrastructure, which covers everything involved in creating, distributing, and revoking certificates. The CA is the part that carries the trust, since every other party relies on the CA having checked identities carefully before signing. You can learn more about public key infrastructure (PKI) in our article What is Public Key Infrastructure.

What does a certificate authority do?

A certificate authority has three jobs, and each one supports the trust that certificates provide. The CA verifies the identity of whoever requests a certificate, so a certificate for a domain is issued only to someone who controls that domain. The CA then issues and signs the certificate, binding the requester’s public key to the verified identity with the CA’s own private key. 

The third job is managing certificates for the rest of their life. A certificate authority publishes which certificates it has issued, sets how long each one is valid, and revokes certificates that are compromised or no longer needed. Revocation is handled through a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP), which let clients reject a certificate that looks valid but has been pulled. Taken together, these jobs make a CA the entity everyone else trusts so they do not have to verify identities on their own. 

How does a certificate authority work?

A certificate authority works through a request-and-signing process that ends in a certificate a client can verify. The process begins when someone generates a key pair and sends the CA a certificate signing request (CSR), which contains the public key and the identity to be certified. The private key never leaves the requester, so the CA certifies the identity without ever seeing the secret half. 

The CA then validates the request. For a public website certificate, validation can be as light as confirming control of the domain or as thorough as verifying a legal organization. After validation succeeds, the CA signs a certificate with its own private key and returns it. From that point, any client can follow the chain of trust, checking that the certificate was signed by the CA, that it has not expired, and that it was not revoked, before trusting the public key inside it. The chain check is the sequence your browser runs every time it shows a padlock.

Root CAs vs intermediate CAs

Certificate authorities are arranged in a hierarchy so the most trusted key is used as little as possible. At the top sits a root CA, whose certificate is distributed with browsers and operating systems and is trusted implicitly. Because compromising a root would break trust for everyone who relies on it, root keys are kept offline in hardware and used rarely.

Beneath the root sit intermediate CAs. A root CA signs one or more intermediate CAs, and those intermediates do the day-to-day work of issuing end-entity certificates to websites, devices, and workloads. If an intermediate is compromised, it can be revoked without invalidating the root, which contains the damage. A client validates a certificate by following the chain from the end-entity certificate through any intermediates back to a root it already trusts, which is what “chain of trust” describes.

Types of certificates a certificate authority issues

A certificate authority issues several kinds of certificates for different purposes. The following table names the common ones and what each is for.

Web certificates are the most visible, but client, device, and workload certificates are the ones that carry infrastructure identity, which is where short certificate lifetimes make the biggest difference.

Public vs private certificate authorities

Certificate authorities come in two forms, and the difference is who is meant to trust them. A public CA issues certificates trusted by the whole internet, because its root is distributed in every browser and operating system. Well-known public CAs include Let’s Encrypt, DigiCert, Sectigo, and GlobalSign, and they are audited against industry requirements so their certificates are accepted everywhere without setup.

A private CA issues certificates trusted only inside one organization. Teams run a private CA to secure internal services, devices, and machine-to-machine traffic, where a public CA would add cost and delay for no benefit. A private CA gives an organization full control over who gets a certificate, what it is valid for, and how short its lifetime is, which is exactly what certificate-based infrastructure identity depends on. Most organizations use public CAs for anything internet-facing and a private CA for everything internal.

Certificate authority trust and security

Because everyone relies on a certificate authority to verify identities correctly, a CA is a high-stakes target. If an attacker gets a CA to issue a fraudulent certificate, they can impersonate a trusted site or service. The 2011 compromise of the Dutch CA DigiNotar showed the danger, producing fraudulent certificates for major domains and ending with the CA being distrusted and shut down, which is why CA security and auditing are taken so seriously.

Protecting a CA comes down to guarding its private keys and limiting how the signing key is used. Root keys are kept offline in hardware security modules, intermediate CAs absorb the day-to-day signing so the root is rarely touched, and short certificate lifetimes limit how long any single certificate stays useful if something goes wrong. Certificate Transparency logs, which record every certificate a public CA issues, add another check by making misissuance detectable. Each of these protections follows the same logic. Shorter lifetimes and tighter control reduce what an attacker can do with a stolen certificate.

Private CAs, short-lived certificates, and infrastructure identity

Running a private certificate authority that issues short-lived certificates has become the way modern teams secure infrastructure. Instead of copying static SSH keys and long-lived certificates across a fleet, a private CA issues a fresh certificate at each login that proves who an actor is and expires within hours. Each human, machine, workload, and AI agent presents a certificate rather than a shared secret, and every server trusts the CA rather than a long list of individual keys.

Short-lived certificates issued by an internal CA remove most of the burden that long-lived certificates create. Nothing has to be rotated by hand, because a new certificate is issued on each use and the old one expires on its own. Offboarding is immediate, because access ends when the certificate lapses or is revoked at the CA. And every certificate is tied to a named identity, so there is a clean answer to who reached a given resource. Issuing short-lived certificates is the move from managing static credentials to cryptographic identity, and it is why teams building zero trust run their own CA. Our article Credentials vs Cryptographic Identity explains the tradeoff between the two, and our article How to Configure SSH Certificate-Based Authentication walks through the SSH-specific setup.

Conclusion

A certificate authority is the trusted entity that verifies identities and signs the digital certificates behind HTTPS, code signing, and certificate-based access. Public CAs secure the open internet, while a private CA that issues short-lived certificates has become the way teams secure their own infrastructure, because shorter lifetimes and tighter control leave attackers far less to work with.