Skip to main content

Certificates

Certificate Authorities: Who Browsers Actually Trust

The organisations that vouch for the identity behind HTTPS.

Quick answer

A Certificate Authority (CA) is a trusted organisation that verifies domain ownership (and sometimes business identity) and issues the digital certificates that make HTTPS work. Browsers ship with a list of trusted root CAs, and any certificate that chains back to one is trusted automatically.

CAs are the backbone of the web's trust model. They validate who is requesting a certificate, sign it with their key, and browsers trust the result because the CA's root is pre-installed. Understanding CAs explains why some certificates are free and instant while others cost money and take days.

Check your website

See how your site handles certificate authorities: who browsers actually trust — free, no account needed.

For business owners

The certificate authority you choose affects cost, how much identity verification you get, and how quickly certificates are issued. For most sites a free, automated CA is perfect; for banks and large brands, higher-assurance certificates that verify the legal entity can add a layer of visible trust. Knowing the difference helps you avoid overpaying — or under-protecting.

How it works (technical)

Certificates come in validation levels: Domain Validation (DV) proves control of the domain and is issued in minutes (e.g. Let's Encrypt); Organisation Validation (OV) and Extended Validation (EV) additionally verify the legal entity. A browser trusts a certificate if it can build a valid chain of trust from the leaf certificate through one or more intermediate certificates to a root in its trust store. Roots are kept offline; intermediates do the day-to-day signing. Misconfigured servers that omit the intermediate cause "certificate not trusted" errors even when the certificate itself is valid.

Real-world example

A site installed only its leaf certificate and forgot the intermediate. Desktop browsers that cached the intermediate worked, but many mobile devices showed a security warning. Installing the full chain (leaf + intermediate) resolved the errors everywhere — a classic CA-chain misconfiguration.

Why it matters

The CA chain determines whether visitors see a padlock or a scary warning. Scanners verify the certificate is issued by a trusted CA and that the full chain is served correctly.

How to fix it

  1. Choose a CA that matches your needs — a free automated DV CA suits most sites.

  2. Install the complete chain: your leaf certificate plus any intermediate certificates.

  3. Verify the chain with an SSL checker to confirm no "incomplete chain" warnings.

  4. For higher assurance, use OV/EV where verified identity adds value.

  5. Automate renewal so certificates never lapse.

Best practices

  • Always serve the full certificate chain, not just the leaf.

  • Automate issuance and renewal (ACME) to prevent expiry outages.

  • Match validation level to risk — DV for most, OV/EV for high-trust brands.

Common mistakes

  • Omitting the intermediate certificate, causing trust errors on some devices.

  • Paying for high-assurance certificates when DV would do.

  • Manually renewing and forgetting, leading to expiry outages.

Frequently asked questions

Are free certificates less secure?

No. A free DV certificate from a trusted CA uses the same encryption as a paid one. Paid certificates add identity verification, not stronger encryption.

Why does my certificate show as untrusted?

Most often the server is not serving the intermediate certificate, so the browser cannot build the chain to a trusted root. Install the full chain to fix it.

Put this into practice

See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.

Scan your website free

See Pro plans · Create account