tls.available Reviewed July 2026

Quick fix

Confirm that the public CDN, load balancer, reverse proxy, or origin listens on TCP 443.

What this finding means

SecuTest performs a verified SNI-enabled TLS handshake on TCP port 443. The check fails when no valid TLS service can be reached or when the endpoint cannot complete a TLS handshake. A network timeout remains indeterminate rather than proving absence.

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 Traffic interception, tampering, and service impersonation

How the attack or failure scenario works

TLS protects data in transit and authenticates the server. When the public service cannot negotiate TLS, users may fall back to plaintext HTTP, abandon the service, or accept unsafe workarounds. An on-path attacker can read or modify plaintext traffic and redirect users to fraudulent content.

Conditions and limitations

  • The application is reachable over an unencrypted or user-bypassable channel.
  • The attacker is positioned on the network path or controls a malicious access network.
  • The user or client continues despite the lack of a valid TLS connection.

Why it matters

Security and business impact An unavailable or invalid TLS service prevents clients from establishing a protected connection and may push users toward insecure alternatives.

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. Confirm that the public CDN, load balancer, reverse proxy, or origin listens on TCP 443.
  2. Install a valid certificate and complete chain for the submitted hostname.
  3. Enable TLS 1.2 and TLS 1.3 and verify SNI routing for every hostname.
  4. Redirect plaintext HTTP to HTTPS only after the TLS endpoint is stable.

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.

OpenSSL verification
openssl s_client -connect example.com:443 -servername example.com -verify_return_error </dev/null

Nginx listener
server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Apache listener
<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Verify the fix

  1. Run `openssl s_client -connect example.com:443 -servername example.com </dev/null`.
  2. Confirm the handshake completes, the hostname matches, and the verification return code is zero.
  3. Run `curl --fail --show-error --head https://example.com/` from an external network.
  4. Repeat the scan from a resolver and network independent of the origin.
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

  • Enabling port 443 at the origin while the CDN or load balancer still has no HTTPS listener.
  • Serving a default certificate for a different hostname because SNI routing is incomplete.
  • Treating a timeout as proof of a permanent TLS configuration failure.

Authoritative references