TL;DR: Browsers trust dozens of Certificate Authorities to issue the certs that secure the web. They aren’t all equally well-run. WQI recognizes a list of mainstream public CAs — the ones with rigorous audits, public Certificate Transparency logging, and a clean track record — and treats being on one of them as a positive signal. “Other” issuers aren’t punished, just flagged: some are fine, some are about to lose root trust.

What is it?

A Certificate Authority (CA) is the third party that signs your TLS certificate so browsers will trust it. The full mechanics are covered in the certificate chain of trust — short version: browsers ship with a list of “root” CAs they trust, and any cert that chains up to one of those roots is automatically trusted by every visitor.

The WQI-specific addition: not every CA in those root stores is equally well-run. We maintain a list of well-known mainstream CAs and treat them as the trust tier. The list in 2026:

  • Let’s Encrypt
  • DigiCert
  • Sectigo (formerly Comodo)
  • Google Trust Services
  • GlobalSign
  • Amazon Trust Services
  • Cloudflare
  • Buypass
  • ZeroSSL
  • IdenTrust
  • Microsoft
  • Entrust

These all have rigorous CA/Browser Forum baseline-requirement audits, public CT logging, and modern issuance practices. They’re the CAs that issue most of the certs you’ll encounter on the public web today.

Why does it matter?

Pragmatically: if you’re on Let’s Encrypt or DigiCert, your cert is almost certainly fine for the next several years regardless of your own operational practices. The CA itself is being actively audited, its issuance pipeline has been reviewed, and any mis-issuance is caught fast through Certificate Transparency monitoring.

If you’re on a CA we don’t recognize, three possibilities:

  1. Regional CA serving a specific market that we just don’t pattern-match — fine, common in non-US/EU markets.
  2. Enterprise / internal CA that you stood up on purpose for non-public use — fine, in fact preferred for internal traffic.
  3. Sketchy CA that’s about to lose root trust. Not fine. These exist; they get caught; their certs all break overnight.

We can’t tell which of the three from the cert alone, so we mark “other” as a warn — a prompt to look at it, not a failure.

Real-world analogy

Issuer reputation is like brand-name vs off-brand vitamins. Mainstream brands have FDA-equivalent oversight; if they screw up the formulation or the labeling, somebody catches it and pulls the bottle from shelves. Off-brand might be perfectly fine — some are great. But it might also be diluted, mislabeled, or expired. Hard to tell from the bottle.

The cert from a CA we recognize is the brand-name vitamin. The cert from “Some Issuer Co Ltd” we’ve never heard of is the off-brand. Most of the time it’s fine. Sometimes it isn’t.

A short history of CA distrust events

Every few years a major CA gets distrusted by browsers because of mis-issuance, audit failures, or outright incompetence. A handful of the bigger ones:

  • DigiNotar (2011). Compromised by an attacker who issued fraudulent certs for Google and other targets. Full distrust within weeks of the breach. The CA went bankrupt.
  • TURKTRUST (2013). Mis-issued an intermediate cert that was used to MITM Google traffic. Removed from major root stores.
  • WoSign / StartCom (2016). Mis-dated certs to evade the SHA-1 deprecation deadline, lied about the relationship between the two brands. Distrusted by Mozilla, Apple, and Google.
  • Symantec / RapidSSL / Thawte / GeoTrust (2017–2018). Years of audit problems and questionable issuance practices. Gradually distrusted by Chrome 66 through Chrome 70; the Symantec PKI business was sold to DigiCert.

When a CA loses trust, every cert they ever issued effectively breaks. Millions of sites have to reissue under a new CA on a deadline. Being on a CA with stable, durable trust is one of the boring infrastructure choices that pays off when the next distrust event lands.

A short note on private / internal CAs

For internal-only certs — corporate intranets, IoT device fleets, dev / staging environments, mTLS between microservices — a private CA that you control is the right choice. You don’t want a public CA issuing certs for internal.corp.example, and the whole CA / Browser Forum audit regime doesn’t apply to your private trust store anyway.

Public web-facing certs should always be from a publicly-trusted CA. WEBQ-97 will score “other” (warn) for private CAs because we can’t recognize them — that’s expected and correct. If your audit target is genuinely an internal-only host, the warn is signal, not noise.

How WQI measures this

We grade issuer reputation as factor WEBQ-97 in the Security category. We pull the issuer Distinguished Name (DN) from the leaf cert and check both the Common Name (CN) and Organization (O) fields, since CAs split their identity across the two differently — for example, Let’s Encrypt’s leaf certs use a CN like R3 or E1 (the intermediate’s name) but the O is always Let's Encrypt. Matching only one field would miss them.

We match the DN against a maintained pattern list and bucket the result into three tiers:

ResultWhat it means
Pass (100)Issuer matches a well-known mainstream CA family.
Warn (60)Issuer is a regional or enterprise CA we don’t recognize. Could be fine, just not a default-trust signal.
Fail (0)Reserved for future explicit distrust-list match.

The fail tier is a placeholder — today, distrusted CAs almost never appear in issued certs because browsers refuse to chain through their roots and operators rotate off them before audit time. We hold the slot open for a future explicit-distrust check.

What good looks like

Pass on WEBQ-97. Cert from a mainstream public CA. There’s no operational benefit to switching off Let’s Encrypt to anywhere else for a typical web-facing site, and switching to a less-known CA introduces real distrust risk for no upside.

How to fix it

If you’re not on the well-known list and you’re public-web, switch issuers. ACME-based issuers are free and well-audited:

The migration is usually one ACME renewal away. Your existing private key and CSR don’t have to change — only the issuer signing the new cert.

For paid certs (EV / OV with extended validation, broader compatibility profiles for legacy device fleets, support contracts):

  • DigiCert — the dominant paid CA, full EV / OV product line.
  • Sectigo — broad product range, common reseller channel.
  • GlobalSign, Entrust, IdenTrust — established paid CAs with enterprise tooling.

Common pitfalls

  • Corporate CA used on a public-facing site by accident. Common during cloud migrations: an internal mTLS service gets exposed publicly without anyone noticing the cert came from the internal CA. Visitors see “untrusted certificate” errors. Fix: re-issue from a public CA.
  • Legacy certs from a CA that’s since been distrusted. Your site might appear to work in older browsers or older OS images while failing in current Chrome / Safari. If the cert was issued by Symantec / RapidSSL / Thawte / GeoTrust pre-2018 and somehow survived, it’s been broken for years. Re-issue.
  • Paid certs from less-known CAs sold as “premium.” Some resellers package OV certs from minor CAs as “professional” or “enterprise” tier. They don’t actually offer audit advantages over Let’s Encrypt — just a higher price tag and a less-recognized issuer. Read the cert chain before buying.

Further reading