A TLS certificate could not be verified

In the reportInvalid or expired TLS certificate

tls_invalid_or_expired · Issue

Short answer

This appears when a recorded certificate-verification verdict identifies a failure for your site's HTTPS origin or a checked address. An expired certificate, an untrusted authority or a name mismatch can cause such a failure. Google lists an invalid certificate among the signals against its HTTPS preference. Review the affected address and renew or replace the certificate where needed.

Severity: High. Fix it soon. It is Critical when your site's own address fails; a failure only on the other homepage version, with or without www, or on another page is High.

Why it matters

Google prefers HTTPS pages unless signals conflict, and one it lists is an HTTPS page with an invalid certificate. It advises avoiding bad certificates because they make Google prefer HTTP very strongly.

What to do

  1. Read the affected address and recorded verification evidence. This finding does not establish the expiry date or issuer.
  2. Renew or replace the certificate so that it covers every name you use and is served with its intermediate certificates.
  3. Check that automatic renewal still works.

What we read

We use retained TLS results from page requests and the shared four-root host check. Certificate verification stays enabled: a failed request is never repeated without it.

The site result also reads the TLS diagnostic's control-certificate verdict for exactly the registered origin. An explicitly unverified control certificate proves a failure; a connection or handshake error without a certificate verdict remains unverified. Another origin's diagnostic cannot establish or clear this finding.

The site finding groups failed HTTPS roots and a failed verdict for the registered origin. A recorded page certificate failure has a page finding unless that exact HTTPS root failure is already owned by the site finding.

Example & evidence

Illustrative example — one audit, not a live result.

Initial site access has passed. A later certificate check records a failure for the registered origin:

Origin: https://bakery.example
Certificate verification: failed

This recorded verdict can produce one Critical site finding. A failed request without a certificate verdict would remain unverified; failure of initial site access would stop the audit before this diagnostic.

A possible correction: renew the certificate for bakery.example and www.bakery.example, then sufficiently recheck the same origin and roots.

Confirm & check again

Check for yourself: open your address in a browser, with and without www, and click the icon beside the address to see the certificate's validity dates and the names it covers.

Check again: Full audit — run an audit that sufficiently rechecks the same subject. A page needs a current verified certificate result. A site needs verified results for both HTTPS roots, no retained failed certificate verdict and, when the registered origin is outside that matrix, its own verified diagnostic verdict. An unavailable root or missing verdict leaves the fix unconfirmed; a page limit alone does not decide it.

Limits & sources

A certificate-related page request error without an explicit certificate verdict remains a coverage gap. If initial HTTPS robots access fails, the audit stops before TLS diagnostics and creates no certificate finding for that failed run.

The crawler's trust store can differ from a browser's. An interception proxy or stale local trust store can also affect verification. This check does not establish certificate dates or issuer, assess HSTS or protocol versions, or inventory asset certificates. For shop.bakery.example, root probes use bakery.example and www.bakery.example; the registered subdomain needs its own exact-origin certificate verdict.

Confidence: High because a finding requires a recorded certificate-verification failure; a generic network error is insufficient.

Sources

Editorial review: 3 November 2026