How SSL Certificates Get Issued: Certificate Authorities, Domain Validation, and the Chain of Trust

Every time you see a padlock in your browser's address bar, a certificate has been issued, verified, and installed. The process that makes this work involves certificate authorities, validation procedures, cryptographic chains, and a set of global policies that govern what is and is not allowed. Understanding how SSL certificates get issued explains both why HTTPS is trustworthy and what happens when the system occasionally breaks.

What a Certificate Actually Is

An SSL certificate is a digital document that binds a public key to an identity. The identity might be just a domain name (for DV certificates), or it might include organisation details (for OV and EV certificates). The document is signed by a certificate authority using that CA's private key, which is what makes it trustworthy — anyone who trusts the CA can verify the signature and therefore trust the binding between the key and the identity.

The certificate contains the domain it was issued for, the public key associated with that domain, the CA that issued it, the dates it is valid between, and the digital signature that ties everything together. When your browser connects to an HTTPS site, the server presents this certificate, the browser verifies the signature and checks the validity period, and if everything checks out, it proceeds with the TLS handshake using the public key in the certificate.

Certificate Authorities

A certificate authority is an organisation trusted to verify identities and issue certificates. There are a relatively small number of root CAs whose certificates are embedded in operating systems, browsers, and other software as trust anchors. When your browser decides whether to trust a certificate, it ultimately traces a chain of signatures back to one of these embedded root certificates.

Root CAs almost never issue certificates directly to websites. Instead, they use their root certificates to sign intermediate CA certificates, and those intermediate CAs do the actual certificate issuance. This limits the exposure of the root private keys: if an intermediate CA is compromised, the root CA can revoke the intermediate's certificate and issue a new one. Compromising a root key itself would be catastrophic, so root CAs keep their keys offline in hardware security modules and use them as rarely as possible.

The market is divided between a handful of major CAs: DigiCert, Sectigo, GlobalSign, Entrust, and the free, automated Let's Encrypt. Let's Encrypt now accounts for the majority of DV certificates on the internet because it automated the issuance and renewal process that previously required manual steps and payment for each certificate.

Domain Validation: How the CA Proves You Own the Domain

Before issuing a certificate for a domain, a CA must verify that the person requesting the certificate actually controls that domain. For Domain Validation certificates, there are three standard methods defined by the CA/Browser Forum, the industry body that sets the rules CAs must follow.

The first method is email validation. The CA sends a verification email to one of a predefined set of addresses for the domain: admin@, administrator@, hostmaster@, postmaster@, or webmaster@ the domain, or to the email address listed in the domain's WHOIS record. Clicking the link in that email proves control of the domain's administrative email.

The second method is HTTP file validation. The CA generates a random token and instructs the requester to place a file containing that token at a specific path on the web server, something like http://yourdomain.com/.well-known/acme-challenge/randomtoken. The CA then fetches that URL and verifies the token is present. If it is, the requester has demonstrated they control the web server for that domain.

The third method is DNS TXT record validation. The CA provides a specific TXT record value that must be added to the domain's DNS zone. The CA then queries DNS for that record. Because adding DNS records requires access to the domain's DNS management, successfully adding the record proves domain control. Let's Encrypt's ACME protocol supports all three methods and uses them to fully automate certificate issuance and renewal.

Organisation and Extended Validation

OV and EV certificates require additional validation beyond domain control. The CA verifies the legal existence of the organisation, typically by checking public business registries, and for EV certificates, performs additional checks on the organisation's identity and authorisation. This verification is done by human reviewers at the CA, which is why OV and EV certificates cost more and take longer to issue.

EV certificates used to display the organisation name in a green bar in browsers, giving a visible indication of enhanced identity verification. Most browsers removed this display in 2019 and 2020, having concluded that users did not meaningfully understand what it indicated. EV certificates still contain the organisation information and some organisations continue to use them for internal policy reasons, but they are no longer visually distinguished in mainstream browsers.

The Certificate Chain

When a server presents a certificate, it typically presents not just the end-entity certificate (the one issued for the specific domain) but also the intermediate CA certificate that signed it. This allows the browser to construct the chain of trust: end-entity certificate signed by intermediate CA, intermediate CA certificate signed by root CA, root CA certificate trusted by the browser.

If a server presents only the end-entity certificate without the intermediate, some clients will fail to validate it because they cannot complete the chain to a trusted root. This is a surprisingly common misconfiguration. Tools like SSL Labs' SSL Test will report it and show which clients are affected. The fix is simply to include the full certificate chain when configuring the server — most certificate issuers provide a bundle file that includes both the certificate and the necessary intermediate certificates.

Certificate Revocation

If a certificate's private key is compromised, or if it was issued in error, the CA can revoke it. There are two main mechanisms for communicating revocation: CRL (Certificate Revocation List), a periodically published list of revoked certificate serial numbers, and OCSP (Online Certificate Status Protocol), a real-time query service where browsers can check whether a specific certificate has been revoked.

In practice, browser vendors have largely moved away from real-time revocation checks because they add latency and can cause connection failures if the OCSP server is unavailable. Chrome, for example, does not perform real-time OCSP checks for most certificates. Instead, major browsers maintain compressed summaries of revoked certificates that are pushed to browsers periodically. Let's Encrypt certificates have a 90-day validity period, so even without revocation the maximum exposure window for a compromised key is relatively short.

Certificate Transparency

Since 2018, Chrome requires that all publicly trusted certificates be logged in Certificate Transparency (CT) logs — publicly auditable append-only logs of every issued certificate. This makes it impossible for a CA to issue a certificate for your domain without it appearing in the public record. Site owners can monitor CT logs for certificates issued for their domains, which provides early warning if a rogue certificate is issued. Services like crt.sh allow anyone to search the CT logs for all certificates issued for a given domain.

CT has significantly improved the accountability of the CA ecosystem. Several CA misissuances have been discovered through CT log monitoring, leading to investigation and, in some cases, CA root certificates being distrusted by browser vendors. The consequence of distrusting a CA root is severe — every certificate issued by that CA suddenly stops being trusted — which gives CAs a strong incentive to follow the rules.