Certificate Authorities in the US: Roles and Trusted Providers
Certificate Authorities (CAs) are the foundational trust anchors of public-key infrastructure (PKI), issuing digital certificates that bind cryptographic keys to verified identities for websites, software, email systems, and federal networks. The US market encompasses both commercial CAs embedded in browser and operating system trust stores and government-operated CAs managed under federal PKI frameworks. Understanding how these entities are structured, audited, and classified is essential for procurement officers, compliance teams, and security architects selecting or evaluating certificate services.
Definition and scope
A Certificate Authority is an entity authorized to issue, revoke, and manage X.509 digital certificates under a defined certificate policy. Certificates issued by a trusted CA enable relying parties — browsers, operating systems, and network devices — to verify that a public key belongs to the entity named in the certificate, forming the basis of TLS/SSL encryption, code signing, and S/MIME email authentication.
The US CA landscape divides into two structural domains. The commercial PKI sector includes globally trusted CAs whose root certificates appear in trust stores maintained by Apple, Google, Microsoft, and Mozilla. The federal PKI sector is anchored by the Federal Public Key Infrastructure (FPKI), operated under the General Services Administration (GSA), which issues certificates for federal agencies, contractors, and interoperability with the Common Access Card (CAC) and Personal Identity Verification (PIV) programs.
Regulatory oversight of commercial CAs in the browser-trusted ecosystem is exercised through the CA/Browser Forum, an industry consortium that publishes binding Baseline Requirements governing certificate issuance, validation, and revocation. Federal CAs must comply with NIST SP 800-57 for key management and with policies set by the Federal PKI Policy Authority (FPKIPA). Explore the Encryption Providers for service providers operating within this framework.
How it works
Certificate issuance follows a defined sequence of validation, signing, and publication steps that differ by certificate class.
- Subscriber request (CSR generation): The applicant generates a key pair and submits a Certificate Signing Request containing the public key and identity data to the CA.
- Identity validation: The CA verifies the applicant's control of the domain or the legal identity of the organization, depending on the validation level (see classification below).
- Certificate signing: The CA's signing infrastructure applies the CA's private key to produce a digitally signed certificate binding the applicant's public key to the verified identity fields.
- Delivery and installation: The signed certificate is returned to the subscriber for installation on servers, signing systems, or identity credentials.
- Publication to CT logs: For publicly trusted TLS certificates, the CA must submit each issued certificate to at least one Certificate Transparency (CT) log, a requirement enforced by Chrome policy since 2018 (Google Certificate Transparency Policy).
- Revocation infrastructure: CAs must maintain Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responders so that relying parties can check certificate validity in real time.
Annual WebTrust or ETSI audits are required for CAs seeking or maintaining root inclusion in major trust stores. The AICPA WebTrust Program for CAs defines audit criteria covering physical security, logical security, and operational practices.
Common scenarios
Federal agency authentication: Agencies issuing PIV credentials to employees rely on the Federal Common Policy CA (FCPCA) as the trust anchor, with subordinate CAs operated by individual agencies or shared service providers. The FPKI currently bridges over 60 agency and affiliate PKIs (GSA FPKI Dashboard).
TLS/HTTPS for public-facing web services: Organizations obtaining publicly trusted TLS certificates choose among Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) certificates, each requiring progressively more rigorous identity verification. DV certificates verify only domain control and are issued in minutes; EV certificates require legal entity verification against official registries, typically taking 1–5 business days.
Code signing: Software publishers use CA-issued code signing certificates to sign executables and scripts. Microsoft's Trusted Root Program governs which CAs can issue certificates recognized by Windows Authenticode. Since June 2023, Microsoft requires code signing keys to be stored on hardware security modules (HSMs), a policy change documented in the Microsoft Trusted Root Certificate Program requirements.
S/MIME email encryption: Enterprise deployments use CA-issued S/MIME certificates to authenticate senders and encrypt message content. The CA/Browser Forum published the first formal S/MIME Baseline Requirements (S/MIME BR) in 2023, covering certificate profiles and validation standards for the first time under a consensus framework. See the for how S/MIME providers are classified within this reference network.
Decision boundaries
Selecting a CA or evaluating CA trustworthiness involves structured distinctions across several dimensions.
Commercial vs. Federal PKI: Commercial CAs issue certificates relying parties across the public internet will trust without additional configuration. Federal CAs under FPKI are not included in commercial browser trust stores by default; their certificates are trusted within the federal ecosystem through specific policy configuration. Organizations that need certificates trusted both by browsers and by federal systems may require separate certificate chains from each domain.
Validation level comparison:
| Level | Identity Verified | Typical Use Case | Issuance Time |
|---|---|---|---|
| Domain Validation (DV) | Domain control only | Internal tools, low-risk sites | Minutes |
| Organization Validation (OV) | Legal entity + domain | Business web properties | 1–3 days |
| Extended Validation (EV) | Enhanced legal + operational vetting | High-assurance banking, e-commerce | 1–5 days |
Root vs. subordinate vs. issuing CA: Trust hierarchies consist of root CAs (offline, self-signed, embedded in trust stores), intermediate/subordinate CAs (cross-certified from roots), and issuing CAs (operationally active, signing end-entity certificates). Compromise at the root level invalidates the entire chain beneath it, which is why root CA private keys are kept offline and protected under strict physical controls documented in the CA's Certificate Practice Statement (CPS).
Short-lived vs. long-lived certificates: The CA/Browser Forum has progressively reduced the maximum validity period for publicly trusted TLS certificates — from 5 years prior to 2015 to 398 days under the current Baseline Requirements (CA/Browser Forum BR v2.0). Proposals within the Forum have called for further reduction to 90 days, a change that would affect certificate renewal automation requirements for all subscribers. For researchers examining the broader encryption services landscape, the How to Use This Encryption Resource page explains how CA-related providers are structured within this reference property.