HTTPS, SSL & Security
What is a certificate authority?
A certificate authority, CA, is an organisation trusted to verify the identity of entities on the internet and issue SSL certificates that cryptographically bind a public key to a verified identity. Certificate authorities are the trust anchors of the web’s security infrastructure, they are the entities that browsers and operating systems trust by default, and this trust propagates to every website whose certificate was issued by a trusted CA.
The certificate authority model exists because public key cryptography, the foundation of HTTPS: requires a way to verify that a public key actually belongs to who it claims to belong to. Without trusted intermediaries anyone could generate a key pair, create a certificate claiming to be bank.com, and use it to impersonate that bank. CAs solve this by performing identity verification before issuing certificates, establishing that whoever received the certificate genuinely controls the domain or organisation the certificate represents.
When a browser connects to https://example.com and the server presents an SSL certificate the browser does not trust the certificate because the website says it should, it trusts the certificate because a certificate authority the browser already trusts has verified the certificate and vouched for it with a cryptographic signature. The trust flows from the browser’s built-in trust store through the certificate authority to the website, this chain of trust is the foundation of all secure web communication.
How certificate authorities work
Certificate authorities operate through a combination of identity verification procedures, cryptographic signing, and trust infrastructure maintained across browsers and operating systems worldwide.
Root certificates and trust stores: every browser and operating system maintains a trust store, a collection of root CA certificates that are trusted by default. These root certificates are the starting points of trust chains. When a browser evaluates an SSL certificate it checks whether the certificate was issued by a CA in its trust store, directly or through a chain of intermediate CAs leading back to a trusted root.
Root certificates are included in trust stores through a formal acceptance process. Browser vendors, Google, Mozilla, Apple, Microsoft, each maintain their own root programs with requirements that CAs must meet to be included. Requirements cover security practices, certificate issuance policies, technical standards, and audit requirements. CAs that fail to meet these requirements can be removed from trust stores, immediately causing all their certificates to trigger browser errors.
Intermediate certificates: root CAs do not typically issue end-entity certificates, the certificates presented by websites, directly. Instead root CAs issue intermediate CA certificates, certificates that authorise other CAs to issue end-entity certificates on behalf of the root. Websites are issued certificates by intermediate CAs. The trust chain from root to intermediate to website certificate is called the certificate chain.
Using intermediate CAs provides security isolation. Root CA private keys are kept in highly secure offline environments, they are used only to sign intermediate certificates, not for day-to-day certificate issuance. Intermediate CA keys are used for actual certificate issuance and can be revoked if compromised without requiring changes to the root CA.
Domain validation process: before issuing a certificate a CA must verify that the requester controls the domain the certificate is being requested for. The validation methods, HTTP-01, DNS-01, and TLS-ALPN-01 challenges for domain validation, prove that the certificate requester has technical control over the domain. Without successful domain validation a CA cannot issue a certificate for that domain.
Certificate signing: after validation the CA creates the certificate containing the public key and domain information and signs it with the intermediate CA’s private key. The signature is a cryptographic proof that the CA has verified the certificate contents. Browsers verify this signature using the CA’s public key to confirm the certificate is genuine and unmodified.
Types of certificate authorities
CAs vary in their size, scope, ownership structure, and the types of certificates they issue.
Commercial CAs: for-profit organisations that sell SSL certificates as their primary business. DigiCert is the largest commercial CA by market share, owning or partnering with several other major CA brands including Thawte, GeoTrust, and RapidSSL. Sectigo, formerly Comodo CA, is another major commercial CA. GlobalSign, Entrust, and Certum are significant commercial CAs serving enterprise customers.
Commercial CAs offer the full range of certificate types, DV, OV, and EV, and provide paid support, warranty coverage, and additional services like certificate management platforms. They are the appropriate choice for organisations that need OV or EV certificates or dedicated support.
Let’s Encrypt: a non-profit CA operated by the Internet Security Research Group. Let’s Encrypt provides free, automated DV certificates through the ACME protocol. As discussed in the Let’s Encrypt article it has transformed HTTPS adoption by removing cost and complexity barriers. Let’s Encrypt is now one of the largest CAs by certificate issuance volume, having issued over three billion certificates.
Google Trust Services: Google operates its own CA, Google Trust Services, that issues certificates for Google’s own services and through the ACME protocol for external use. Google Trust Services uses the gts certificate identifier. Available as an ACME CA for organisations that prefer Google’s infrastructure.
ZeroSSL: a free certificate authority operating on a similar model to Let’s Encrypt, offering free DV certificates through the ACME protocol. ZeroSSL also offers paid plans with additional features. An alternative to Let’s Encrypt for organisations that want ACME-based free certificates from a different CA.
Buypass: a Norwegian CA offering free DV certificates through ACME alongside paid OV and EV certificates. Provides an alternative free certificate source to Let’s Encrypt with slightly longer 180-day validity periods.
Cloud provider CAs: major cloud platforms operate their own certificate infrastructure for resources on their platforms. AWS Certificate Manager issues free certificates for use with AWS services, CloudFront, ELB, API Gateway. Google-managed SSL certificates are available for Google Cloud Load Balancing. Azure provides managed certificates through Azure App Service. These cloud CA certificates are available only within their respective cloud ecosystems, not for external use.
Certificate authority trust hierarchy
The trust hierarchy is the structured relationship between root CAs, intermediate CAs, and end-entity certificates that forms the basis of browser trust evaluation.
Root CA: the top of the trust hierarchy. Root CA certificates are self-signed, they vouch for themselves. Browsers trust root CAs because they were explicitly included in the trust store through the root program process, not because they can prove their trustworthiness through another trusted party. Root CA private keys are the most sensitive cryptographic material in the web PKI, their compromise would allow the issuance of trusted certificates for any domain.
Intermediate CA: a CA whose certificate was signed by a root CA or another intermediate CA. Intermediate CAs are used for day-to-day certificate issuance, keeping the root CA private key offline in secure hardware. A single root CA may have multiple intermediate CAs for different purposes, separate intermediates for DV, OV, and EV certificates, for different geographic regions, or for different product lines.
End-entity certificate: the certificate presented by websites during TLS handshakes. Signed by an intermediate CA. Contains the domain names covered by the certificate and the public key. The end-entity certificate is what browsers examine and evaluate during HTTPS connections.
Certificate chain validation: browsers validate SSL certificates by following the chain from the end-entity certificate through intermediate certificates to a trusted root. Each certificate in the chain is verified against the next, the end-entity certificate is signed by the intermediate CA, the intermediate CA’s certificate is signed by the root CA or a higher intermediate, and the chain eventually reaches a trusted root.
The full certificate chain must be presented by the server, browsers cannot always independently retrieve intermediate certificates. A server that presents only the end-entity certificate without the intermediate CA certificates causes validation failures in some browsers, the browser cannot verify the chain without the intermediate certificates.
The CA/Browser Forum
The CA/Browser Forum, CABF, is an industry consortium of certificate authorities and browser vendors that defines baseline requirements for SSL certificate issuance and CA operations. The forum’s Baseline Requirements are the minimum standards that all publicly trusted CAs must meet.
Baseline Requirements: the CABF Baseline Requirements cover certificate content and profile requirements, validation procedures, revocation mechanisms, audit requirements, and CA operational security. Requirements include maximum certificate validity periods, currently 398 days maximum, domain validation methods, prohibition on issuing certificates for internal names, and many other technical and procedural standards.
All publicly trusted CAs must comply with the Baseline Requirements as a condition of remaining in browser trust stores. Browser vendors enforce compliance through their root programs, CAs that fail to comply face sanctions including removal from trust stores.
Certificate Transparency requirement: the CABF and browser vendors require all publicly trusted certificates to be logged in Certificate Transparency logs before browsers will trust them. CT logging creates a publicly auditable record of all certificate issuances, allowing domain owners, researchers, and security teams to detect unauthorised certificate issuance for their domains.
Historical CA incidents: the CA system has experienced significant trust incidents that illustrate the importance of the oversight mechanisms. DigiNotar, a Dutch CA, was compromised in 2011 and issued fraudulent certificates for Google, Microsoft, and many other major sites. The incident was discovered through anomalous certificates being used in attacks in Iran. DigiNotar was removed from all browser trust stores and the company failed as a result.
Symantec CA, once the largest commercial CA, was found to have issued thousands of certificates in violation of CABF requirements over several years. After extended remediation attempts that failed to satisfy browser vendors Google and Mozilla announced they would distrust all Symantec-issued certificates, a process completed in 2018 that required all Symantec certificate holders to re-obtain certificates from other CAs. DigiCert acquired Symantec’s CA business and rebuilt it on compliant infrastructure.
These incidents demonstrate that CA trust is not permanent, it is conditional on continued compliance with baseline requirements and responsible incident response.
Certificate authorities and redirect management
Certificate authorities are the source of the SSL certificates that make HTTPS redirect management possible. Every domain connected to redirect infrastructure needs certificates from a trusted CA, without them HTTPS connections to redirect source domains fail before any redirect response can be served.
Let’s Encrypt for automated redirect SSL: redirect management platforms universally use Let’s Encrypt or equivalent ACME-based CAs for automated certificate provisioning. When a domain is connected to redirect infrastructure the platform’s ACME client requests a certificate from Let’s Encrypt, completing a DNS-01 or HTTP-01 challenge to prove domain control and receiving the issued certificate automatically. This automation scales to hundreds or thousands of connected domains without manual certificate management.
CAA records restricting CA choice: domain owners who have configured CAA records restricting certificate issuance to specific CAs must ensure the CA used by their redirect management platform is listed. If the platform uses Let’s Encrypt, as most do, the domain’s CAA records must include letsencrypt.org. CAA records that omit Let’s Encrypt prevent the platform from obtaining certificates for the domain, causing HTTPS to fail for connected domains.
Certificate chain presentation: redirect management infrastructure must present the complete certificate chain, end-entity certificate plus intermediate CA certificates, during TLS handshakes. Incomplete chain presentation causes validation failures in some browsers. Properly configured redirect management platforms include the full chain automatically.
Certificate revocation monitoring: if a certificate used by redirect infrastructure is revoked, because its private key was compromised, browsers that check revocation status will fail to connect until a new certificate is provisioned. Monitoring certificate health and having automated re-issuance processes ensures that revocation events are handled promptly without extended redirect outages.
Checking certificate authority information
Understanding which CA issued a certificate and verifying the certificate chain is achievable through standard tools.
Browser certificate details: clicking the padlock icon in the browser address bar and viewing certificate details shows the issuing CA, the certificate chain, and all certificate contents. Chrome shows the certificate under Security → Certificate Information. Firefox shows it under the padlock icon → More Information → View Certificate.
Certificate transparency search: crt.sh provides a searchable interface to CT logs, searching for a domain shows all certificates issued for it across all CAs. Each certificate entry shows the issuing CA, the SANs, the validity period, and the CT log entries. CT search is the most comprehensive way to audit what certificates exist for a domain and which CAs have issued them.
OpenSSL chain inspection:
Shows the complete certificate chain presented by the server, the end-entity certificate, intermediate CA certificates, and information about each. Useful for verifying the complete chain is being served correctly.
SSL Labs issuer analysis: the SSL Labs SSL Test shows the certificate chain graphically, displaying the end-entity certificate, intermediate CA certificates, and root CA with trust status for each. Provides the clearest visual representation of the trust chain for a given domain.