TLS and SSL Certificates: Versions, Expiry and HSTS

Reviewed October 2026.

At a glance

Setting	Aim for
Protocol versions	TLS 1.2 and TLS 1.3 only
Certificate	From a public CA, sent with its full chain, covering every name the site answers on
Renewal	Automated, with expiry monitored separately
Cipher suites	Authenticated encryption with forward secrecy; nothing weak or broken
Plain HTTP	Every request redirected to HTTPS, with an HSTS header on HTTPS responses

Protocol versions

SSL 2.0 and 3.0 and TLS 1.0 and 1.1 are obsolete. RFC 7568 prohibited SSL 3.0 in 2015, and RFC 8996 said in 2021 that TLS 1.0 and 1.1 must not be used. RFC 9325, the current IETF guidance on using TLS, says implementations must support TLS 1.2 and should support TLS 1.3.

TLS 1.3 (RFC 8446) removed the legacy options behind many past attacks. Every cipher it offers is an authenticated (AEAD) cipher, static RSA and Diffie-Hellman key exchange are gone so every connection has forward secrecy, and more of the handshake is encrypted. NCSC guidance is to use TLS 1.3 and/or TLS 1.2, and to plan a move to TLS 1.3 if you use only 1.2, because TLS 1.2 will not be updated to support post-quantum cryptography.

On nginx, set ssl_protocols TLSv1.2 TLSv1.3;; on Apache, SSLProtocol -all +TLSv1.2 +TLSv1.3. CDNs and managed hosts usually have a minimum TLS version setting: set it to 1.2. Current browsers no longer offer TLS 1.0 or 1.1, so turning them off affects only very old clients and devices.

TLS version checker See whether a server still accepts SSL 3.0, TLS 1.0 or TLS 1.1, and whether it offers TLS 1.3.

Findings and fixes are in the TLS protocol versions check reference.

Certificates and trust

A certificate binds your domain names to a public key and is signed by a certificate authority (CA) that browsers trust. A browser accepts it when the chain leads to a trusted root, the dates are current and the name matches.

Use a certificate from a publicly trusted CA. Self-signed and private-CA certificates produce warnings for the public.
Send the full chain: your certificate and the intermediate certificates between it and the root. Some browsers can fill in a missing intermediate; many other clients, such as scripts and API integrations, cannot, so the fault can be invisible in your own browser.
NCSC recommends ECDSA keys on the P-256 curve, or RSA keys of 2048 bits, with SHA-256.
Keep private keys only on the servers that need them, readable only by the service that uses them, and replace the certificate if a key may have been exposed.

Publicly trusted certificates are recorded in certificate transparency logs (RFC 6962), which anyone can search. Two things follow: every name you put on a certificate becomes public, and you can watch the logs for certificates issued for your names that you did not request.

Certificate checker Read a site's TLS certificate: the names it covers, its issuer, validity and trust.
Subdomain finder Find a domain's subdomains in public certificate transparency logs.

Findings and fixes are in the certificate validity and certificate transparency check references.

The names a certificate covers

Browsers match the name in the address bar against the certificate's subject alternative names. A name missing from that list gives a hostname mismatch warning, however valid the certificate is otherwise.

Cover both the bare domain and www, even if one only redirects to the other. The redirect is served over HTTPS, so it needs a valid certificate too.
A wildcard such as *.example.com matches exactly one label (RFC 9525). It covers www.example.com, but not example.com or a.b.example.com.
A wildcard shares one private key across every service that uses it, so a key exposed on one server affects all of them. Where renewal is automated, a certificate per service costs little.
Remember services other than the website that use your names, such as mail servers and VPN gateways. They need valid certificates as well.

Expiry and automation

Certificates are getting shorter-lived. Under the CA/Browser Forum Baseline Requirements, a public TLS certificate issued on or after 15 March 2026 may be valid for at most 200 days. The limit falls to 100 days from 15 March 2027 and to 47 days from 15 March 2029. At those lifetimes, renewing by hand means an outage sooner or later.

ACME (RFC 8555) automates issuance and renewal. A client on your server, or your host or CDN on your behalf, proves control of each name and installs the new certificate. The two common challenge types are http-01, which serves a token from the website, and dns-01, which publishes a TXT record and so also works for names that serve no website. Let's Encrypt and many other CAs support ACME, and most managed hosts and CDNs run it for you.

Automation still fails, and often quietly. Common causes:

A DNS or firewall change stops the challenge reaching the server.
A CAA record does not list the CA the client uses.
The certificate renews, but the server keeps serving the old one until it is reloaded.
Warnings about failed renewals go to the mailbox of someone who has left.

So watch expiry from outside, separately from the renewal itself. Ironfang's certificate expiry check reports a certificate that expires within 30 days.

Certificate expiry checker See when a site's TLS certificate expires and how many days are left.

Findings and fixes are in the certificate expiry check reference.

Cipher suites

A cipher suite fixes how a connection agrees keys, encrypts and checks its data. TLS 1.3 defines only a few, all of them sound. For TLS 1.2 the server's configuration decides, and old defaults can still allow weak suites.

Refuse NULL, RC4 and export-grade suites, which RFC 9325 forbids, and anonymous suites, which authenticate nobody.
Avoid static RSA key exchange (suites starting TLS_RSA_WITH_). It has no forward secrecy: anyone who later obtains the server's private key can decrypt recorded traffic. Use ECDHE suites.
Prefer AEAD ciphers, AES-GCM or ChaCha20-Poly1305. Keep CBC suites only if you must serve old clients, and drop 3DES, which RFC 9325 rates below the 128 bits of security it recommends.

RFC 9325 recommends four TLS 1.2 suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. NCSC's recommended profiles use ECDHE with AES-128-GCM for TLS 1.2, and TLS_AES_128_GCM_SHA256 for TLS 1.3. Rather than writing a cipher list by hand, use your platform's modern preset, or Mozilla's SSL Configuration Generator for common servers.

TLS cipher checker See whether a server accepts broken or weak cipher suites such as RC4, 3DES or export ciphers.

Findings and fixes are in the cipher suites check reference.

HTTPS redirect and HSTS

TLS protects a connection only once it is made over HTTPS. Redirect every plain HTTP request to the same path over HTTPS with a permanent redirect (301 or 308), then send Strict-Transport-Security on HTTPS responses so that browsers go straight to HTTPS next time.

HSTS (RFC 6797) also changes how browsers treat certificate errors. On a site with HSTS there is no option to click through a warning, so an expired or mismatched certificate makes the site unreachable rather than merely alarming. That is the protection working, and one more reason to automate renewal. Values and preloading are covered in HTTP security headers.

HSTS checker Check Strict-Transport-Security: max-age, includeSubDomains, preload and the HTTP redirect.

Findings and fixes are in the HTTPS redirect and HSTS check references.

Checking your configuration

SSL/TLS checker Check a site's HTTPS, certificate, expiry, TLS versions and weak cipher suites.
TLS version checker See whether a server still accepts SSL 3.0, TLS 1.0 or TLS 1.1, and whether it offers TLS 1.3.
TLS cipher checker See whether a server accepts broken or weak cipher suites such as RC4, 3DES or export ciphers.

What a check can show, and what it cannot

Ironfang can check

Whether the site answers over HTTPS and redirects plain HTTP to it
Which SSL and TLS versions the server accepts, and whether it offers TLS 1.3
Whether weak or broken cipher suites are accepted
Whether the certificate is trusted, in date and valid for the name, and how long it has left
Whether HSTS is sent, and its max-age

The organisation must establish

An inventory of certificates, including those on mail servers, VPNs and other services
Who owns renewal for each, and who is told when it fails
How private keys are stored, and who can read them
What happens when a key may have been exposed

The External Security Check runs these checks on a verified domain with the DNS, email and header checks, keeps the results with the domain's history, and can recheck on a schedule.

Sources

Checked on the review date above. Standards and schemes change; the source is the authority.

TLS and certificates