Public Key Infrastructure (PKI) is the foundational security framework that enables encrypted communications and identity verification across the internet. At the center of every PKI ecosystem sits the Certification Authority (CA)—a trusted entity responsible for issuing, managing, and validating digital certificates. Without CAs, the modern web as we know it would lack the trust required for e-commerce, email encryption, software signing, and secure authentication. Understanding the CA's role is essential for anyone involved in cybersecurity, network administration, or digital policy.

What Is a Certification Authority (CA)?

A Certification Authority is an organization or technical service that issues digital certificates to bind a public key to an identity—such as a domain name, individual, or organization. These certificates follow the X.509 standard (defined in RFC 5280) and are used to establish authenticated, encrypted connections, most notably in SSL/TLS for HTTPS websites. CAs operate as the cornerstone of trust: browsers, operating systems, and applications include a pre‑loaded list of trusted root CAs, and any certificate issued by a CA in that list is considered valid by default.

CAs are classified into two main categories:

  • Public CAs (e.g., DigiCert, Entrust, Let’s Encrypt) are publicly trusted and audited to comply with industry standards like WebTrust for CAs or ETSI EN 319 411. They issue certificates that are automatically accepted by mainstream browsers.
  • Private CAs are operated internally by an organization (e.g., using Microsoft Active Directory Certificate Services, OpenSSL, or HashiCorp Vault) to issue certificates for internal networks, device authentication, or code signing. Their root certificates must be manually installed by administrators to be trusted.

Within a PKI hierarchy, a CA can function as a Root CA (self‑signed, at the top of the trust chain) or as an Intermediate/Subordinate CA (cross‑signed by the Root CA to issue end‑entity certificates). This tiered model limits risk: if an intermediate CA is compromised, the root key remains secure and can revoke the offending intermediate.

Core Functions of a Certification Authority in PKI

Certificate Issuance and Identity Validation

The primary function of a CA is to issue digital certificates after verifying the applicant’s identity. The level of validation determines the certificate type and the trust conveyed:

  • Domain Validation (DV) – The CA proves control over a domain, typically by responding to an email or DNS challenge. DV certificates are cheap, automated (often via the ACME protocol), and ideal for basic TLS encryption, but they offer no organizational identity assurance.
  • Organization Validation (OV) – The CA performs manual checks on the requesting organization’s legal existence, address, and phone number. OV certificates display verified business information in the certificate subject.
  • Extended Validation (EV) – The highest assurance level, requiring rigorous vetting by the CA. Browsers historically displayed the company name in green or a special indicator. While EV’s visual prominence has diminished, it still provides stronger legal and audit assurances.

The validation process is governed by the CA/Browser Forum’s Baseline Requirements, which standardize checks across public CAs.

Certificate Lifecycle Management

Once issued, a digital certificate enters a lifecycle that the CA must manage:

  • Renewal – Certificates have finite validity periods (typically 1–2 years for TLS certificates, sometimes 90 days for automated services like Let’s Encrypt). Renewal involves re‑validation and issuance of a new certificate with a fresh key pair.
  • Re‑keying – If the private key is suspected compromised, the subscriber can request a new certificate with a new public key.
  • Expiry – Expired certificates are automatically rejected by TLS clients; the CA must provide clear renewal workflows to prevent service disruption.
  • Revocation – When a certificate is no longer trusted (compromised private key, domain change, or incorrect information), the CA adds its serial number to a Certificate Revocation List (CRL) and/or updates an Online Certificate Status Protocol (OCSP) responder.

Trust Anchoring and Chain Building

The CA’s root certificate serves as a trust anchor. During TLS handshakes, the server presents its leaf certificate along with any intermediate certificates, forming a certificate chain that ends at a root certificate trusted by the client. The CA ensures that every link in the chain is cryptographically valid and that no expired or revoked intermediates are used. Browsers periodically refresh their trust stores to add new root CAs or remove distrusted ones.

How CAs Verify Identities: Mechanisms and Standards

Identity verification methods vary by certificate type and CA policy. For DV, the CA uses automated challenges:

  • DNS TXT record – The CA provides a random value that the applicant places as a DNS TXT record; the CA queries the domain’s DNS to confirm ownership.
  • Email validation – A verification email is sent to a well‑known administrative address (e.g., [email protected]). The applicant clicks a link or enters a code.
  • HTTP/HTTPS file upload – The applicant places a file with a specific token on the web server for the CA to retrieve.

For OV and EV, the CA conducts manual checks:

  • Verification of business registration in official government databases.
  • Phone call to a listed number to confirm the request.
  • Physical address validation via third‑party business databases or utility bills.

These procedures are defined in the CA/B Forum’s EV Guidelines and Baseline Requirements. CAs must undergo annual audits by a qualified auditor (e.g., WebTrust for CAs, ETSI) to demonstrate compliance.

Revocation Mechanisms: Maintaining Trust in Real Time

When a certificate is revoked prematurely, the PKI must inform relying parties (e.g., browsers, email clients). Two mechanisms are standard:

  • Certificate Revocation Lists (CRLs) – A periodically published list of revoked certificate serial numbers. Clients download and cache these lists, but they can become large and slow to update. CRL distribution points are embedded in certificates.
  • Online Certificate Status Protocol (OCSP) – A real‑time protocol where clients query the CA’s OCSP responder with the certificate’s serial number to get a good/revoked/unknown response. OCSP stapling allows the server to pre‑fetch and present a time‑stamped OCSP response during the TLS handshake, improving performance.

Timely revocation is critical: a delayed revocation can leave compromised certificates exploitable. Browsers impose strict limits on the time between reporting a compromise and placing the certificate on revocation lists.

Security Challenges and Notable CA Incidents

Despite rigorous audits, CAs have been compromised or misoperated, undermining global trust:

  • DigiNotar (2011) – Attackers breached DigiNotar’s infrastructure and issued fraudulent certificates for domains including google.com. The CA was quickly removed from trust stores and declared bankrupt.
  • Comodo (2011) – An attacker gained access to a registration authority and issued nine fraudulent certificates for high‑profile domains. The incident led to stronger multi‑factor authentication for CA operators.
  • Symantec (2017–2018) – Google discovered systematic misissuance of certificates by multiple Symantec‑owned CAs (e.g., Thawte, VeriSign). Over several years, trust was gradually eroded, culminating in the distrust of all Symantec‑issued certificates in 2018.
  • Trustico (2018) – A reseller claimed to have retained private keys for thousands of certificates, violating the fundamental principle that private keys must never be exposed. The incident highlighted the risks of CA resellers and third‑party key management.

These events drove improvements in CA security practices, including increased use of Certificate Transparency logs, automated certificate lifecycle management, and stricter key generation protocols.

Automated Certificate Management (ACME Protocol)

The Automated Certificate Management Environment (ACME) protocol, defined in RFC 8555 and popularized by Let’s Encrypt, revolutionized certificate issuance by enabling fully automated DV certificate validation, issuance, and renewal. ACME allows web servers to obtain certificates without manual intervention, significantly reducing administrative overhead and the risk of human error. Today, many CAs (including private CA solutions) support ACME, and it is a key enabler of the 90‑day certificate validity standard.

Certificate Transparency (CT)

CT is an open auditing system that requires all publicly trusted TLS certificates to be logged in an append‑only ledger. Browsers (e.g., Chrome) enforce CT for all certificates issued by public CAs. CT logs make it difficult for CAs to secretly issue fraudulent certificates, as users and auditors can monitor all issued certificates. CAs serve as log operators or submit certificates to third‑party logs.

Shift to Short‑Lived Certificates

Industry trends (led by Google, Apple, and the CA/B Forum) are pushing certificate lifetimes down from 2–3 years to 90 days or less. Short‑lived certificates reduce the window of vulnerability if a private key is compromised and drastically simplify revocation (expiration replaces revocation in many cases). This trend demands robust automated renewal workflows, further cementing the role of ACME and other automation frameworks.

Conclusion

The Certification Authority remains the linchpin of PKI ecosystems, enabling secure identities for websites, devices, code, and users. From issuing validated certificates to managing revocation and anchoring trust in browsers, CAs perform a demanding set of responsibilities that directly impact online security. As the internet continues to evolve toward shorter certificate lifetimes, automated issuance, and greater transparency, the CA’s role will shift from manual oversight to automated governance—without ever losing its critical function of verifying identity and preserving trust. Anyone working with digital certificates must understand how CAs operate, how they are audited, and how emerging standards are shaping a more resilient PKI landscape.

For further reading, explore the CA/Browser Forum’s Baseline Requirements and industry audit frameworks such as WebTrust for CAs.