Web PKI

Web PKI (Web Public Key Infrastructure) is the collection of technical mechanisms, certificate authorities, browser and operating-system trust stores, policies, and audit practices that underpin HTTPS and other TLS-based services on the Web. It uses X.509 certificates to bind public keys to DNS-based identifiers (primarily domain names) so that browsers can authenticate web servers and establish encrypted connections.

Concept

In IETF terminology, the Web PKI is the subset of the wider Internet PKI used to protect communications between Web browsers and Web content servers, including the certificate fields, status information, and TLS stacks that browsers rely on when evaluating server certificates. It is built on the X.509 certificate framework defined by ITU-T and profiled for Internet use in RFC 5280, which specifies how subject names, subject alternative names, key usages, and certificate extensions are represented and validated.

Web PKI is distinct from enterprise or government PKIs: trust in publicly-trusted web certificates is determined by browser and OS vendors’ root programs and by industry rules coordinated through the CA/Browser Forum, rather than by a single central authority.

Architecture and Actors

The Web PKI relies on a public key hierarchy anchored in a set of "root" certificates distributed with browsers and operating systems. Each root CA issues subordinate CA certificates, which in turn issue end-entity certificates for specific DNS names. Browsers validate a presented certificate by building a chain from the server certificate to a trusted root, checking name binding, validity period, key usage, and revocation status.

Key actors include:

• Certification Authority (CAs), which issues and manages certificates and operate OCSP/CRL status services;
• Registration Authority (RAs), which performs identity and domain-control checks on behalf of CAs;
• Browser and OS vendors, which maintain root programs specifying which CAs are trusted and under what conditions;
• Relying parties (end-users and applications), which consume certificates and make trust decisions based on browser UI and policy.

The CA/Browser Forum Baseline Requirements (BRs) define a common set of technical, validation, lifecycle and audit requirements for publicly-trusted TLS server certificates. These include constraints on certificate lifetimes, key sizes, permitted algorithms, validation methods, and the use of Certificate Authority Authorization (CAA) DNS records.

Operational Practices

Operationally, Web PKI centres on issuing, renewing, and revoking certificates for DNS names. Issuance typically follows Domain Validation (DV), Organisation Validation (OV) or Extended Validation (EV) processes, with domain control proved via DNS, HTTP, or email-based challenges. The BRs and browser root policies specify which methods are allowed and how often validation data may be re-used. Revocation is signalled via Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). In practice, browsers combine OCSP, OCSP stapling and soft-fail behaviour in different ways, and historically revocation checking has been a weak point of the ecosystem.

The [[CA/Browser Forum] has progressively reduced maximum certificate lifetimes (for example, to 398 days in 2020 and towards roughly 47 days by 2026) to limit the window of exposure if a certificate or key is compromised.

Governance Aspects

The Web PKI sits at the intersection of several governance and standardisation spaces:

• The IETF defines core technical standards such as RFC 5280 for certificate profiles, TLS protocol versions, OCSP, and Certificate Transparency.
• The CA/Browser Forum is a voluntary industry body of CAs and "certificate consumers" (browsers and other applications) that produces the Baseline Requirements and EV Guidelines. These documents are not formal standards but act as de facto policy for participation in major root programs.
• Browser and OS root programs (Mozilla, Chromium/Chrome, Apple, Microsoft and others) ultimately decide which CAs are trusted and can apply additional conditions, including requiring CT logging or imposing stricter incident-reporting timelines.

These layers are largely independent of ICANN, which governs the DNS root and the delegation of TLDs but does not regulate CAs or browser trust stores. The Web PKI nonetheless depends on the DNS naming system managed through ICANN processes: certificates bind keys to DNS names rooted in the public namespace (with a few exceptions for Special-Use Domain Names), and mis-issuance often involves confusion or attacks at the DNS level as well as within CA operations.

Interaction with DNS and Special-Use Names

Because Web PKI identities are expressed primarily as DNS names, changes in the DNS namespace and special-use reservations have direct implications for certificate issuance. The CA/Browser Forum’s Baseline Requirements restrict certificates for internal names and reserved IP space, and require CAs to check CAA records at issuance time.

The treatment of .onion provides a notable example of coordination between Web PKI rules, IETF special-use reservations and ICANN’s DNS role. After RFC 7686 registered .onion as a Special-Use Domain Name, CA/Browser Forum Ballot 144 and subsequent ballots defined conditions under which CAs could issue certificates containing onion addresses, initially for EV and later also for DV/OV certificates using version 3 onion names.

More broadly, research and operator commentary highlight CAA and DANE as points where DNS- and Web PKI–centric governance meet: both mechanisms allow name owners to express PKI-related constraints in DNS, while CT provides an external audit trail over the certificates that CAs actually issue.

Incidents

The Web PKI has experienced several high-profile CA compromises and mis-issuance incidents (such as DigiNotar in 2011 and later enforcement actions against other major CAs), which exposed the risks of a model where any trusted CA can issue a certificate for almost any domain name.

Measurement work shows that trust is concentrated: a relatively small number of CAs account for the majority of publicly-trusted web certificates, and a small set of browser/OS vendors control the dominant root programs. This concentration simplifies coordination but raises concerns about single points of failure and geopolitical or commercial leverage over a critical security infrastructure.

Automation has also changed the Web PKI’s operational profile. ACME-based issuance and services such as Let’s Encrypt have made short-lived certificates and continuous renewal routine, improving security in many deployments but also increasing dependence on a few large, automated CAs and their corresponding policies.

See Also

• DNSSEC
• Special-Use Domain Names
• .onion

X.509 Public Key Infrastructure for the Internet (RFC 5280).

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

Internet Engineering Task Force

Hypertext Transfer Protocol. Application-level protocol for distributed, collaborative, hypermedia information systems (RFC 2616).

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Top-Level Domain