SSL certificate, chain and TLS health checks

1. SSL Certificate Summary

This block in the report summarises the main properties of the certificate currently served by your web server.

Why the certificate summary matters

A quick glance at this summary tells you whether the certificate matches the domain, who issued it, how long it is valid for and how strong the key and signature algorithms are.

How DNSprobe builds the certificate summary

DNSprobe reads the CN, SANs and organisation from the subject, the issuer name and validity dates, then combines the signature hash with the public key type and size into a compact line such as “SHA256 / RSA 4096 bits”. It also labels the certificate as DV, OV or EV and notes whether it is wildcard or multi-domain.

Best practices for the certificate itself

• Use at least SHA-256 with a 2048-bit RSA key or a modern EC key; avoid outdated algorithms such as SHA-1 or short keys.
• Ensure the CN and SANs explicitly cover all hostnames you serve (for example example.com and www.example.com).
• Renew certificates well before they expire and avoid overlapping test certificates that could be served accidentally.

Example key summary: SHA256 / RSA 4096 bits.

2. Certificate chain and intermediates

The chain details section visualises the relationship between your leaf certificate, intermediate authorities and the root certificate.

Why the certificate chain is important

Many connection errors and trust warnings are caused by incomplete chains, where the web server fails to send the correct intermediate certificates to clients.

How DNSprobe validates the chain

DNSprobe verifies that each certificate in the chain is signed by the next one, highlights broken links with a red “X”, and offers a one-click download of individual PEM files or the full chain so you can install the missing intermediates.

Best practices for certificate chains

• Always configure your web server to send the full chain (leaf + all required intermediates).
• Use the vendor’s “bundle” file for commercial CAs or the official chain files for Let’s Encrypt instead of mixing certificates from different sources.
• If DNSprobe reports an incomplete chain, follow the hint URL to download the correct intermediates from your CA.

3. HSTS header status

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your domain, even if users type an explicit http:// URL.

Why HSTS is linked to SSL

Without HSTS, a user’s very first visit might still use plain HTTP, which exposes them to downgrade and hijacking attacks on unsecured networks.

How DNSprobe checks HSTS

DNSprobe sends a HTTPS request to your site and looks for the Strict-Transport-Security header on the final response, showing the exact value it received or explaining that HSTS is not enabled.

Best practices for HSTS

• Start with a moderate max-age and enable HSTS only once you are sure everything on the site works over HTTPS.
• When you are confident, move towards a long max-age, include subdomains and consider preloading your domain.
• Avoid enabling HSTS on domains that must stay reachable over HTTP (for legacy services or mixed-content constraints).

DNSprobe also provides a dedicated HSTS section and wiki page with configuration examples for Apache, LiteSpeed and Nginx.

4. TLS versions and key strength

The SSL report lists which TLS protocol versions your server accepts and evaluates the size of the certificate’s public key.

Why modern TLS versions matter

Obsolete protocols such as TLS 1.0 and 1.1 no longer provide acceptable security and are disabled in most modern browsers and libraries.

How DNSprobe tests TLS support

DNSprobe uses the OpenSSL client to attempt connections with TLS 1.0, 1.1, 1.2 and 1.3 and records the versions that successfully complete a handshake.

Best practices for TLS configuration

• Disable SSLv3, TLS 1.0 and TLS 1.1; prefer TLS 1.2 and TLS 1.3 only.
• Use strong cipher suites and a minimum key size of 2048 bits for RSA or an equivalent EC key.
• Keep your web server and OpenSSL libraries up to date to benefit from security patches and new protocol features.

5. SSL Evaluation Score and recommendations

At the bottom of the SSL section, DNSprobe assigns a score out of 5 and lists concrete actions to improve your HTTPS configuration.

What the SSL score represents

The score reflects five key aspects: certificate validity, completeness of the chain, HSTS, modern TLS support and key length, with penalties when the certificate does not match the domain.

How DNSprobe calculates the score

One point is awarded for each of the following: a non-expired certificate with more than 30 days remaining, a complete chain, HSTS enabled, TLS 1.2 or 1.3 support and a key size of at least 2048 bits. Mismatched CN/SAN entries reduce the score and trigger a warning.

Using the SSL score in practice

• Treat a “Fail” score as urgent, especially if users see browser warnings when visiting your site.
• Aim for a full 5/5 by fixing chain issues, enabling HSTS safely and enforcing modern TLS versions.
• Re-run DNSprobe after each change to verify that the score and recommendations reflect your new configuration.

6. Test SSL/TLS manually from your own terminal

DNSprobe inspects your certificate, chain, key type and size, HSTS header and supported TLS versions. You can reproduce most of these checks from a terminal using OpenSSL and curl to see exactly what your server presents to clients.

Linux: using OpenSSL and curl

On most Linux distributions, the openssl and curl tools are available in the default repositories. The following commands show the negotiated TLS protocol, the certificate chain and the HTTP security headers (including HSTS) for your site:

                openssl s_client -connect example.com:443 -servername example.com
    
                # Basic check: see the negotiated protocol, certificate and chain for example.com    
                openssl s_client -connect example.com:443 -servername example.com -showcerts
    
                # Show the full certificate chain as PEM output (leaf + intermediates)    
                curl -I https://example.com/
        

macOS: using the built-in OpenSSL and curl

On recent versions of macOS, you can use openssl and curl from the Terminal to inspect the certificate chain and HTTP headers. The commands below work the same way as on Linux:

                openssl s_client -connect example.com:443 -servername example.com
    
                # Basic check: see the negotiated protocol, certificate and chain for example.com    
                openssl s_client -connect example.com:443 -servername example.com -showcerts
    
                # Show the full certificate chain as PEM output (leaf + intermediates)    
                curl -I https://example.com/
        

Windows: using OpenSSL and curl (or WSL)

Windows does not ship with OpenSSL by default, but you can get it via Git for Windows, third-party packages or the Windows Subsystem for Linux (WSL). Once openssl is available in your PATH, you can run the same commands as on Linux/macOS and use curl from Command Prompt or PowerShell:

                openssl s_client -connect example.com:443 -servername example.com
    
                REM Use an OpenSSL build from Git for Windows, Chocolatey, winget, or run this from WSL    
                curl -I https://example.com/
    
                REM Retrieve only the HTTP response headers (including Strict-Transport-Security if present)    
                wsl openssl s_client -connect example.com:443 -servername example.com
        

Important: only test hosts and domains that you own or are authorised to analyse. Running repeated TLS and header checks against third-party systems without permission may be treated as abusive behaviour by some providers.