Certificate Authorities in the US: Roles and Trusted Providers
Certificate authorities (CAs) form the operational backbone of trusted digital communication across the United States, issuing and revoking the digital certificates that authenticate websites, software, email systems, and networked devices. This page covers how CAs are classified, how the issuance process is structured, which regulatory and industry frameworks govern CA operations in the US, and how organizations determine which CA tier or certificate type fits a given deployment requirement.
Definition and scope
A certificate authority is a trusted third-party entity authorized to issue X.509 digital certificates that cryptographically bind a public key to a verified identity — whether that identity belongs to a domain, an organization, or an individual. The authority of a CA rests entirely on its inclusion in the trust stores maintained by browser vendors and operating system developers; a CA not present in those stores has no practical reach in public-facing deployments.
In the US, CA operations intersect with public key infrastructure governance at multiple levels. The CA/Browser Forum — a voluntary consortium of CAs and browser vendors — publishes the Baseline Requirements that set minimum standards for certificate issuance, revocation, and auditing. Compliance with these requirements is enforced through annual audits conducted against either the WebTrust for CAs criteria or the ETSI EN 319 411 standard. Federal deployments operate under an additional layer: the Federal Public Key Infrastructure (FPKI), managed by the General Services Administration (GSA), which operates its own Federal Common Policy CA (FCPCA) and anchors trust for US government certificate chains.
CAs are classified along two primary axes:
- Public vs. private — Public CAs issue certificates recognized in commercial browser trust stores. Private CAs issue certificates for internal use within an organization's own infrastructure and are not publicly trusted by default.
- Root vs. intermediate — Root CAs sit at the apex of a certificate chain and are self-signed. Intermediate CAs (also called subordinate CAs) are signed by a root and perform the majority of end-entity certificate issuance; this architecture limits exposure of the root's private key.
How it works
Certificate issuance follows a structured process governed by the CA/Browser Forum Baseline Requirements (CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates):
- Certificate request — The applicant generates a public-private key pair and submits a Certificate Signing Request (CSR) containing the public key and identity claims to the CA.
- Domain validation (DV) — The CA confirms control over the submitted domain through one of three approved methods: DNS record placement, HTTP file placement, or email to a registered contact. DV certificates require no identity vetting beyond domain control.
- Organization validation (OV) — The CA verifies the legal existence of the requesting organization against government registries before issuing. OV certificates carry the verified organization name in the certificate's Subject field.
- Extended validation (EV) — The most rigorous tier; the CA performs full identity vetting including legal jurisdiction, physical address, operational existence, and requester authorization. EV issuance timelines typically run 1–5 business days depending on the CA.
- Certificate signing — The CA cryptographically signs the certificate using its intermediate CA private key, embedding validity period, serial number, and permitted key usages.
- Publication and revocation infrastructure — The CA publishes certificate status through Online Certificate Status Protocol (OCSP) responders and Certificate Revocation Lists (CRLs). Since 2022, the CA/Browser Forum has required CRL entries for TLS certificates, moving away from OCSP-only deployments for end-entity certificates.
The certificate's role in TLS/SSL encryption protocols is foundational: browsers verify the certificate chain from end-entity through intermediate to root before establishing an encrypted session.
Common scenarios
HTTPS website certificates represent the highest-volume CA use case. Domain-validated TLS certificates, issued by public CAs, secure the majority of web traffic. According to the Let's Encrypt Certificate Transparency logs, Let's Encrypt alone had issued over 3 billion certificates as of 2023, predominantly short-lived 90-day DV certificates.
Code signing certificates authenticate software binaries and scripts, establishing publisher identity and confirming the code has not been modified since signing. Code signing certificates are issued under OV or EV validation tiers; EV code signing certificates carry immediate SmartScreen reputation on Windows platforms without the accumulation period required for OV.
Federal agency deployments use PIV (Personal Identity Verification) certificates issued under the FPKI framework, governed by NIST Special Publication 800-157 (NIST SP 800-157). These certificates authenticate federal employees and contractors to government systems and are not issued by commercial public CAs.
Email encryption and signing use S/MIME certificates, issued by public CAs to verified email addresses. Email encryption standards such as S/MIME require a CA that validates the email address and, at higher tiers, the individual's identity.
Decision boundaries
Selecting a CA tier or certificate type depends on the authentication assurance level required, the deployment environment, and applicable compliance mandates.
| Factor | DV Certificate | OV Certificate | EV Certificate |
|---|---|---|---|
| Identity assurance | Domain control only | Legal org verified | Full identity vetting |
| Issuance time | Minutes | Hours–days | 1–5 business days |
| Compliance fit | General HTTPS | Internal/external orgs | High-trust financial, legal |
| FIPS 140 relevance | Indirect | Indirect | Indirect |
Organizations subject to FIPS 140 encryption standards must ensure the cryptographic modules used by their CA infrastructure carry validated status under FIPS 140-2 or FIPS 140-3 — a requirement separate from certificate validation tier. The NIST Cryptographic Module Validation Program (CMVP) maintains the authoritative list of validated modules (NIST CMVP).
Private CA deployments using tools such as Microsoft Active Directory Certificate Services or open-source alternatives operate outside public trust stores but are appropriate for encryption key management scenarios confined to internal infrastructure, provided the private root is distributed through enterprise device management.
The CA/Browser Forum maximum certificate validity for publicly trusted TLS certificates is currently 398 days, established as a binding requirement in 2020 and enforced through browser rejection of non-compliant certificates — a hard constraint that affects certificate lifecycle automation planning regardless of which public CA is selected.
References
- CA/Browser Forum – Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
- NIST SP 800-157 – Guidelines for Derived Personal Identity Verification (PIV) Credentials
- NIST Cryptographic Module Validation Program (CMVP)
- GSA Federal Public Key Infrastructure (FPKI)
- Let's Encrypt Statistics
- NIST SP 800-32 – Introduction to Public Key Technology and the Federal PKI Infrastructure