TLS configuration explained

1 Introduction

The padlock in the address bar is TLS: the protocol that encrypts traffic between a visitor and your server, and proves the server really is example.com and not someone in the middle. Every HTTPS page, API call and login form depends on it.

TLS has two halves you control as the owner: the configuration of your server (which protocol versions and encryption algorithms it accepts) and the certificate it presents (who issued it, which names it covers, when it expires). The TLS block of a domain scan reports on both. Most problems it finds are fixed in a few lines of server configuration or by automating certificate renewal.

2021

TLS 1.0 and 1.1 formally deprecated by the IETF (RFC 8996)

1.2 + 1.3

The only protocol versions a public website should accept today

47 days

Maximum certificate lifetime voted by the CA/Browser Forum for 2029, down from 398

2 How It Works

Before any page is sent, the browser and the server run a handshake. The scanner does the same thing a browser does: it connects to your domain on port 443, completes a handshake, and records what came out of it.

Negotiate

The client lists the versions and cipher suites it supports. The server picks one of each from its own allowed list.

Prove identity

The server sends its certificate and the intermediate certificates that link it to a root authority the client already trusts.

Verify

The client checks the chain, the dates, and that the name it asked for is listed in the certificate. Any failure means a browser warning.

Reading the TLS block of the report

The chips at the top summarise that one handshake: Protocol (green for TLSv1.2 or TLSv1.3), Cipher (the suite that was negotiated), Trusted (did the chain validate), Hostname (match or mismatch) and Expires in, which turns red under 15 days. Below them you find the certificate's subject, issuer and validity dates, then the Findings list with what the scanner flagged. If the block says "No TLS service responded on port 443", your domain serves no HTTPS at all on its main name.

3 Detailed Analysis

Protocol versions

SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 all have known weaknesses and are refused by current browsers. TLS 1.2 is still safe when configured well, and TLS 1.3 (RFC 8446, 2018) removed most of the old options that caused trouble. Accept those two and nothing else:

# nginx
ssl_protocols TLSv1.2 TLSv1.3;

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3

The chip shows what was negotiated, not everything you allow

A green TLSv1.3 means a modern client got a modern connection. An old version can still be enabled for clients that ask for it. To test one explicitly: openssl s_client -connect example.com:443 -tls1_1. A handshake failure is the result you want (some recent OpenSSL builds refuse to even try, which proves nothing about your server).

Check every place TLS ends

If a CDN, load balancer or hosting panel sits in front of your server, the version visitors get is set there, not in nginx. Look for a "minimum TLS version" setting in that product and set it to 1.2.

"But an old client needs TLS 1.0"

Very old devices and embedded systems sometimes do. Give them a separate hostname with its own configuration rather than weakening the main site for every visitor.

Cipher suites

A cipher suite is the bundle of algorithms used for one connection: key exchange, encryption and integrity. The name shown in the report, for example TLS_AES_256_GCM_SHA384 or ECDHE-RSA-AES128-GCM-SHA256, reads like a recipe.

TLS 1.3: nothing to choose

The TLS 1.3 suites that servers enable by default are all considered safe. If your connection negotiates TLS 1.3, the cipher is fine.

TLS 1.2: keep ECDHE with AES-GCM or ChaCha20-Poly1305

ECDHE gives forward secrecy: a key stolen tomorrow cannot decrypt traffic recorded today. Suites that start with plain RSA key exchange lack it. Remove anything with RC4, 3DES, NULL, EXPORT or anon in its name.

Do not hand-craft the list. Copy the "intermediate" profile from the Mozilla SSL Configuration Generator for your server and version. For nginx, the core of it looks like this:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Certificate validity: trust, name and dates

These are the checks that cause the full-page browser warning, so they come first when something is red.

Trusted: no

The chain did not validate. The usual causes: a self-signed certificate, an expired one, or a missing intermediate. The last one is sneaky: some desktop browsers fetch the missing piece on their own, so the site looks fine to you, while curl, mobile apps and API clients fail. In nginx, ssl_certificate must point to the full chain file (with certbot, fullchain.pem, not cert.pem).

Hostname: mismatch

The certificate does not list the name that was requested. Browsers only look at the Subject Alternative Name (SAN) list, not the Common Name. The classic case is a certificate for www.example.com served on example.com. Reissue it with both names.

Expires in: under 15 days

With automated renewal, a certificate is normally replaced around 30 days before expiry. If it is still there with two weeks left, renewal is probably failing silently (a changed DNS record, a firewall blocking the ACME challenge, a cron job that no longer runs). Run the renewal by hand (certbot renew --dry-run) and read the error.

Shorter lifetimes are coming: automate now

Public certificates were capped at 398 days in 2020, and the CA/Browser Forum has voted step-by-step reductions down to 47 days by 2029. Renewing by hand once a year will stop being possible. Use ACME (Let's Encrypt, or your CA's ACME endpoint) or your host's managed certificates.

What to fix first

Urgent: expired or untrusted certificate, hostname mismatch, or an expiry date days away. Visitors already see a warning, or will soon.

Important: TLS 1.0 or 1.1 still accepted, or weak cipher suites enabled. No warning is shown, but the connection is weaker than it should be.

Hygiene: automate renewal, then add HSTS so browsers never try plain HTTP (see HTTP security headers) and restrict who may issue your certificates (see CAA and Certificate Transparency).

Check your domain on mlab.sh

A domain scan runs a TLS handshake against your site and reports the negotiated protocol and cipher, whether the certificate is trusted, matches your name, and how long it has left.

Scan your domain on mlab.sh

4 Red Flags

Certificate expired or about to expire

Browsers block the site with a full-page warning. If renewal is automated, a certificate this close to expiry means the automation is broken.

Self-signed or untrusted chain

Visitors cannot tell your server from an attacker's. Teaching users to click through the warning is worse than the warning itself.

Hostname mismatch

Often a forgotten www or apex name, or a default certificate from the hosting provider. Reissue with every name you serve.

TLS 1.0 or 1.1 negotiated

If the scanner itself ended up on an old version, your server prefers or only offers it. Set ssl_protocols TLSv1.2 TLSv1.3; or the equivalent on your CDN.

Cipher without ECDHE, or with RC4 or 3DES

A sign of a configuration copied years ago and never updated. Replace it with a current Mozilla profile rather than patching it line by line.

Related Modules

Certificates, CAA and Certificate Transparency

Who may issue certificates for your domain, what public certificate logs reveal, and why shared certificates matter.

HTTP security headers explained

HSTS, CSP, X-Frame-Options, cookie flags: what each header blocks, what a missing one means in a scan, and a safe configuration to start from.

Known vulnerabilities on your website

How a scan matches software versions to CVEs, what CVSS, EPSS and CISA KEV mean, and how to prioritise patching.