tls.certificate_valid Reviewed July 2026

Quick fix

Identify whether the failure is hostname, chain, trust, or validity related from the scan evidence.

What this finding means

SecuTest uses the system trust store to verify the chain and hostname during the TLS handshake. A failure can result from an unknown issuer, missing intermediate, invalid dates, revocation-related issues, or a certificate that does not cover the scanned hostname.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Man-in-the-middle interception and server impersonation

How the attack or failure scenario works

A man-in-the-middle attack places an unauthorized system between the client and server. Certificate validation is what lets the client detect that the presented public key is not trusted for the requested hostname. When users ignore warnings, an attacker controlling the network path can decrypt or alter traffic.

Conditions and limitations

  • The certificate fails trust or hostname validation.
  • The victim ignores the browser or client warning, or the client is configured not to validate certificates.
  • The attacker can intercept DNS, routing, Wi-Fi, proxy, or another network path.

Why it matters

Security and business impact An untrusted, incomplete, expired, or hostname-mismatched certificate prevents clients from authenticating the server and encourages dangerous warning bypasses.

Step-by-step fix

Where to make the change

  • The public TLS termination point: CDN, load balancer, reverse proxy, ingress controller, or web server.
  • The origin server only when it directly terminates the externally observed TLS connection.

Remediation procedure

  1. Identify whether the failure is hostname, chain, trust, or validity related from the scan evidence.
  2. Issue a certificate containing every required DNS name from a publicly trusted CA or the correct private PKI.
  3. Serve the leaf certificate followed by all required intermediate certificates.
  4. Deploy the certificate at every public TLS termination point and remove fallback default certificates.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Inspect chain and SANs
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error </dev/null

Inspect certificate fields
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Verify the fix

  1. Run OpenSSL with SNI and `-verify_return_error`.
  2. Inspect Subject Alternative Names and confirm the exact hostname is present.
  3. Test from multiple public networks and a standard browser without bypassing warnings.
  4. Verify automated renewal and chain deployment before the next expiration.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Installing only the leaf certificate and omitting intermediates.
  • Testing the origin certificate while the public CDN serves a different one.
  • Disabling certificate verification in clients instead of correcting the server.

Authoritative references