Certificate does not chain to a trusted root

CriticalConfirmedtls.certificate.untrusted-root

What this check looks for

The certificate cannot be traced back to an authority browsers trust, so it is rejected the same way an expired or mismatched one is.

Why it matters

Visitors see a security warning and most leave. Anything automated — mobile apps, payment callbacks, monitoring — fails with no way to click through.

When the check passes, your report says: “The certificate chains to a root browsers trust”.

What it costs your score

When this check fails it removes 60 points from your TLS score, before the status, confidence and repeat multipliers are applied. TLS carries a weight of 15 in the overall score.

It shares the tls.certificate family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from TLS. One underlying problem showing up in several places is still one problem.

Severity: critical
Default confidence: confirmed
Status when triggered: fail
Deduction: 60 points
Family cap: tls.certificate · 60
Category: TLS
Module: Tls certificate
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Serve a certificate from a publicly trusted CA, with its full intermediate chain.

A chain a client cannot build is a chain a client will not accept.

If this is an internal CA, get a public certificate for anything the public reaches.
If the root is public, install the intermediate certificates the CA supplies — most 'works for me' cases are a missing intermediate.
Serve the leaf first, then the intermediates, and do not serve the root.

How to confirm it worked

openssl s_client -connect ‹host›:443 -servername ‹host› </dev/null 2>&1 | grep 'Verify return code' — expect 'ok'

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# fullchain.pem is the leaf followed by every intermediate, in that order.
ssl_certificate     /etc/letsencrypt/live/‹host›/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/‹host›/privkey.pem;

Apache

SSLCertificateFile    /etc/letsencrypt/live/‹host›/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/‹host›/privkey.pem

Caddy

‹host› {
	tls /etc/ssl/‹host›/fullchain.pem /etc/ssl/‹host›/privkey.pem
}

Cloudflare

SSL/TLS → Overview → set Full (strict), which makes Cloudflare itself validate the origin's chain rather than accepting any certificate.

Apache 2.4.8 and later read the intermediates out of SSLCertificateFile; SSLCertificateChainFile is obsolete and ignored.
Cloudflare's certificate covers visitor-to-edge only. If the origin is reachable directly — by IP address, or through a DNS record that is not proxied — its own certificate is unchanged and is what this scan measured. Fix the origin as well, and set SSL/TLS mode to Full (strict) so Cloudflare itself validates it.

Technical detail

Path building for ‹host› failed against the Mozilla root store: ‹verification error›. The issuer presented was ‹issuer›.

The usual causes are a private or internal CA that only your own machines trust, a missing intermediate that lets *your* browser succeed by cached fetch while a fresh client fails, or a root that has been distrusted by browsers since the certificate was issued. The verdict here comes from a real path build, not from inspecting the certificate's text.