Certification Authority

Certification Authority (CA) is an organisation that issues and signs X.509 digital certificates used to authenticate domain names and enable encrypted connections on the Web (primarily via TLS and HTTPS). In the context of the Web PKI, a CA’s authority derives less from a formal public mandate than from inclusion in major browser and operating-system trust stores and adherence to ecosystem policy requirements.

Role in the Web PKI

CAs issue end-entity certificates that bind a public key to a DNS identifier (for example, a domain name) and sign those certificates under intermediate and root certificates. Browsers validate a presented certificate by building a chain to a trusted root and applying profile and policy rules, including name constraints, key usage, validity periods, and revocation signalling, as profiled in RFC 5280.

In practice, CAs operate within a set of de facto global policy regimes: the CA/Browser Forum’s Baseline Requirements (BRs) describe common issuance, validation, lifecycle, and audit expectations for publicly trusted TLS server certificates, while root programs impose their own additional constraints and incident-handling requirements.

Governance and Accountability

From an Internet Governance perspective, certificate authorities sit in an unusual institutional position: they are private entities that effectively mediate global trust for Web authentication, yet their “regulatory” environment is largely established through private coordination (CA/Browser Forum) and platform gatekeeping (browser/OS trust stores), rather than treaty-based or intergovernmental processes.

Accountability mechanisms include:

• Root program governance: vendors can impose requirements, demand disclosures, and ultimately remove trust for CA roots or intermediates, which can have global operational impact for websites and services relying on that CA.
• Audits and compliance reporting: root programs and the BRs rely heavily on periodic audits and public audit statements as prerequisites for continued inclusion.
• Public transparency measures: Certificate Transparency (CT) is designed to make issuance observable by requiring public logging of certificates, enabling third parties to detect mis-issuance and audit CA behaviour at scale.

Incidents and Trust Concentration

Because any broadly trusted CA can potentially issue certificates for many domains, CA compromise or mis-issuance can undermine authentication at Internet scale. The 2011 compromise of DigiNotar is widely cited as a key stress test: fraudulent certificates were issued, major vendors distrusted the CA, and the firm ultimately collapsed, illustrating how trust-store decisions function as an enforcement tool with systemic consequences.

Concentration also matters. A limited set of browser vendors controls dominant root programs, and a relatively small number of CAs issue a large share of publicly trusted certificates. This can simplify coordination (for example, rapid rule changes through root programs), but it also concentrates leverage over a critical security dependency into a small set of institutions.

Interaction with DNS and Naming Policy

Although CAs are not part of ICANN’s contractual regime, the Web PKI is structurally coupled to the DNS namespace that ICANN coordinates: certificate identities are predominantly DNS names, and changes in naming policy (TLD delegation, reserved labels, and Special-Use Domain Names) can have downstream effects on validation practices and certificate eligibility.

Conversely, the PKI has developed DNS-based controls. The Certification Authority Authorization (CAA) record allows domain holders to publish, in DNS, which CAs are authorised to issue certificates for their domain, providing a governance “hook” at the DNS layer that can reduce mis-issuance risk when properly enforced by CAs.

Automation and Market Structure

The IETF’s ACME protocol enables automated domain validation and certificate issuance at large scale, reshaping CA operations and lowering issuance costs for many services. Operationally, this increases reliance on automated validation channels (including DNS-based validation) and shifts governance pressures toward lifecycle management requirements (shorter certificate lifetimes, faster revocation, and stronger incident-response expectations) primarily set by the BRs and root programs.

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

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

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

Top-Level Domain

Internet Engineering Task Force