TLS remediation guide

TLS certificate validation

Investigate certificate trust or hostname validation failures and verify a complete, correctly scoped replacement deployment.

Reviewed

Check identity

tls.certificate
Finding
tls.certificate.invalid
Severity
critical

What the check observes

The scanner opens a bounded TLS connection for the exact authorized hostname on the supported HTTPS endpoint.

Certificate validation requires a trusted chain and coverage for the authorized hostname. The worker does not disable certificate verification to make the check pass.

Only short typed evidence is retained; the raw certificate and connection transcript are not stored as scanner output.

Why the result matters

Browsers and API clients may reject a certificate that is untrusted, expired, or issued for a different hostname.

A failed deployment can interrupt user access or train users to ignore certificate warnings, so the result deserves prompt validation.

How to investigate

  1. 1

    Confirm the finding’s exact hostname and avoid testing a different alias that may terminate TLS elsewhere.

  2. 2

    Review the leaf certificate’s subject names, validity window, issuer chain, and the chain presented by the public endpoint.

  3. 3

    Check each relevant edge, CDN, proxy, or load balancer for inconsistent certificate deployment.

Remediation steps

  1. 1

    Issue or select a certificate from a trusted authority that covers the exact authorized hostname.

  2. 2

    Deploy the leaf certificate with the required intermediate chain to every public TLS termination point.

  3. 3

    Remove obsolete bindings after confirming traffic has moved to the corrected certificate.

Verify the change

Test the exact hostname from a clean client path and confirm both hostname and trust validation succeed.

Run a new authorized scan and confirm the certificate check passes; verify other hostnames separately because coverage is target-specific.

Limits of this check

  • A passing certificate check does not prove the application, private keys, certificate authority, or TLS configuration is free of vulnerabilities.
  • Safe External v1 does not claim exhaustive cipher, protocol, revocation, or certificate-transparency analysis through this code-owned check.
Keep learning
View all coverage
TLS

TLS certificate expiration

Respond to the Safe External 30-day warning window and confirm that renewal automation delivered the right certificate everywhere.

Read guide
HTTP

HTTP to HTTPS redirects

Configure and verify a same-host HTTPS upgrade so visitors who begin with HTTP are not left on an unencrypted connection.

Read guide

See how findings are presented

Explore a clearly labeled fictional report before adding an asset.

View sample report