Certificate Authorities and the Trust Chain

What Is a Certificate Authority?

A Certificate Authority (CA) is an organization that issues SSL/TLS certificates after verifying the identity of the applicant. Before a certificate is issued, the CA checks that the requester actually controls the domain, and — depending on the certificate type — may also verify the legal existence and details of the organization behind it.

CAs operate under strict industry standards governed by the CA/Browser Forum, a body that sets the rules all publicly trusted CAs must follow. These rules cover everything from how identity verification is performed to how long certificates can be valid. CAs that fail to meet these standards can have their root certificates removed from browser trust stores — effectively making their certificates untrusted worldwide.

The level of verification depends on the certificate type — DV confirms only domain control, OV additionally verifies the organization's legal existence, and EV performs the most thorough check including legal, operational, and physical verification of the company.

The Trust Chain

SSL certificates are not issued directly from a CA's most trusted root certificate. Instead, they follow a three-level hierarchy — commonly called the chain of trust: Root CA sits at the top. Root certificates are self-signed and are pre-installed in the trust stores of browsers and operating systems. Because they are the ultimate anchor of trust, CAs keep root private keys in highly secured, air-gapped environments and use them as rarely as possible.

Intermediate CA sits in the middle. The root CA issues one or more intermediate certificates, which are then used to sign end-entity certificates on a day-to-day basis. This layer exists to protect the root — if an intermediate is ever compromised, it can be revoked and replaced without touching the root.

End-entity certificate is your SSL certificate — issued by the intermediate CA, covering your specific domain or domains, and installed on your server.

When a browser connects to your site, it walks up this chain: it checks your certificate, then the intermediate that signed it, then the root that signed the intermediate. If every signature is valid and the root is in the browser's trust store, the connection is trusted. If any link in the chain is missing or invalid, the browser displays a security warning.

✔ Tip: Your server must send the intermediate certificate alongside your SSL certificate during the TLS handshake. A missing intermediate is the most common cause of trust errors — even when the root CA is fully trusted.

Root Programs — Who Decides What to Trust?

The list of trusted root certificates in any given browser or operating system is maintained by its root program. Microsoft, Apple, Mozilla, and Google each run their own root programs and independently decide which CAs to include. A CA must apply, meet strict technical and policy requirements, and pass regular audits to remain in these programs.

This is why browser compatibility is not guaranteed by default — a CA trusted by Chrome is not automatically trusted by Firefox or Safari. In practice, the major publicly trusted CAs are included in all programs, but it underlines why choosing a well-established CA matters.

GoGetSSL and Certificate Authorities

GoGetSSL works exclusively with two of the most widely trusted CA families in the industry: DigiCert and Sectigo. Their root certificates are included in all major trust stores — Microsoft, Apple, Mozilla, Google, and device manufacturers — ensuring that certificates issued through GoGetSSL are recognized across virtually all browsers, operating systems, and devices in active use.

Under the DigiCert family, GoGetSSL also offers certificates under the GeoTrust, RapidSSL, and Thawte brands — all backed by the same DigiCert root infrastructure. Sectigo certificates are issued under Sectigo's own root chain. Both families have decades-long track records and meet all current CA/Browser Forum requirements.