TLS Configuration Checker

Server assisted New Website & HTTP Diagnostics

Runs one full handshake and up to five restricted ones (TLS 1.0, 1.1, 1.2 and 1.3 only, then weak suites only) from the Mutqan server on Cloudflare's network, reads Strict-Transport-Security on port 443 and grades the result from A+ to F, listing the reason for every cap. A probe that gets no usable answer is reported as inconclusive, never as a refusal; hosts served through Cloudflare cannot be reached by these raw connections.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

Which TLS versions and cipher suites should a server accept?

A current server accepts TLS 1.3 (RFC 8446) and TLS 1.2, refuses TLS 1.0 and 1.1, which RFC 8996 deprecated, and prefers forward-secret AEAD suites such as ECDHE with AES-GCM or ChaCha20-Poly1305 for TLS 1.2 (RFC 9325). RC4, NULL and export suites must never be negotiated, 3DES and RSA key transport should not be, and a web server should also send Strict-Transport-Security so browsers stop trying plain HTTP.

How to use TLS Configuration Checker

  1. Enter the host name, an IP address or a URL; change the port if the TLS service is not on 443.
  2. For an IP address, such as an origin server behind a CDN, put the site name in Server name (SNI).
  3. Press Check TLS configuration and wait up to about 20 seconds: the probes run one after another.
  4. Read the grade and its explanation, then the Protocol versions table. Fix what caps the grade (usually TLS 1.0/1.1 or a missing HSTS header) and run the test again.

TLS Configuration Checker features

  • Tests each protocol version on its own: separate ClientHellos offering only TLS 1.0, only 1.1, only 1.2 and only 1.3 show what the server really accepts, not just what it picks first
  • Offers a hello made only of weak suites (RC4, 3DES, NULL, EXPORT, anonymous, MD5) and lists any the server accepts
  • Reports the negotiated suite with its key exchange, forward secrecy and AEAD status, the ALPN protocol and the handshake time
  • Reads Strict-Transport-Security on https://host/ and parses it as RFC 6797 does, so max-age=0 counts as HSTS switched off
  • An A+ to F grade built from caps, with the reason for every cap — no hidden points, and no grade at all when the certificate could not be read
  • Inconclusive probes are shown as ? instead of being counted as refusals, so a firewall hiccup cannot make a server look stricter than it is
  • A short certificate summary (expiry, name match, chain complete, chain signatures) so the grade's certificate rules can be read in context

Inputs and outputs

Inputs

  • Host name or URL: a name, an IPv4 or IPv6 address, host:port or a URL; only the host and the explicit port are used.
  • Port: 443 by default; any TLS service port works (8443, 993, 995, 465…).
  • Server name (SNI), optional: the site to request from an IP address or a shared server. HSTS is evaluated only when it equals the host.

Outputs

  • Summary: the grade, the negotiated version, forward secrecy, AEAD, whether TLS 1.0/1.1 are refused, the number of weak suites accepted and the HSTS max-age in days.
  • Grade explanation: each cap with its level (for example "C: TLS 1.0 is still enabled."), or what A+ still needs, or why no grade was given.
  • Protocol versions: ✓, ✗ or ? for TLS 1.3, 1.2, 1.1 and 1.0, with the RFC that defines or deprecates each.
  • Negotiated connection, HSTS directives, the weak suites accepted (when any) and a certificate summary.

TLS Configuration Checker example

A server with TLS 1.3 and 1.2 only, HSTS for one year (illustrative result)

Input:

Host name: www.example.com · Port: 443

Output:

Grade A+ · Negotiated TLS 1.3 · Forward secrecy ✓ · AEAD cipher ✓ · TLS 1.0/1.1 refused ✓ · Weak suites accepted 0 · HSTS 365 d
Grade explanation: TLS 1.3 with forward secrecy and AEAD, no legacy protocol, a chain whose links and signatures verify (trust is not evaluated), and HSTS of at least 180 days.
Protocol versions: TLS 1.3 ✓ · TLS 1.2 ✓ · TLS 1.1 ✗ · TLS 1.0 ✗
Negotiated connection: TLS_AES_256_GCM_SHA384 (0x1302) · key exchange TLS1.3 · ALPN h2

How to read the TLS Configuration Checker results

A+ and A both mean that these checks found no weakness; A+ additionally needs evidence of TLS 1.3, TLS 1.0 and 1.1 refused, a conclusive weak-cipher probe, chain signatures that verify and HSTS of at least 180 days. The line under an A says which of those is missing.

B usually means the negotiated suite has no forward secrecy (RSA key exchange) or uses CBC instead of AEAD. C usually means TLS 1.0 or 1.1 is still enabled, 3DES is accepted, or the certificate is self-issued or signed with SHA-1. F means a certificate or cipher problem that browsers refuse outright.

? in the Protocol versions table is not a pass and not a fail: the probe got no usable answer. A rate-limiting firewall or a load balancer that drops quick reconnects is the usual cause; run the test again before acting on it.

HSTS "not evaluated" is not a finding against the server: the header could not be tied to this endpoint (an IP address, another port or another SNI), so the grade simply cannot reach A+.

When to use TLS Configuration Checker

  • Confirm that TLS 1.0 and 1.1 are really off after a configuration change, and that TLS 1.3 is on.
  • Check a load balancer, a reverse proxy or a mail server on 993 or 465 that a browser-based scanner cannot reach.
  • Show a security reviewer the reason behind a grade, cap by cap, rather than a bare letter.
  • Test an origin server directly by IP address and SNI to compare its settings with what the CDN in front of it offers.

Troubleshooting

  • "Served through Cloudflare": raw connections from a Cloudflare Worker to Cloudflare's addresses are blocked by the platform. Cloudflare's edge TLS settings are in its dashboard (SSL/TLS); test your origin by IP address with the site name as SNI.
  • Several versions show ?: the server or a firewall in front of it limits how fast new connections may be opened. Wait a minute and run the test again.
  • "refused the TLS handshake (alert: handshake_failure)" on the main handshake: the server accepts none of the suites offered — for example a server that allows only ChaCha20 under TLS 1.3, which the main handshake cannot offer, or one that requires a client certificate.
  • The request timed out: the full test makes up to six handshakes plus an HTTP request inside about 22 seconds. A very slow server can run out of time; the quick SSL Certificate Checker uses a single handshake.
  • No grade: the certificate could not be read (a TLS 1.3 server whose encrypted Certificate message the probe could not decrypt, and a TLS 1.2 fallback that failed). The protocol and cipher results are still valid.

Frequently asked questions about TLS Configuration Checker

How is the grade calculated?

By caps, not points. Each finding limits the grade to a level and the worst one wins: an expired certificate, a name mismatch, a broken signature, RC4, NULL or export suites mean F; TLS 1.0 or 1.1 still enabled, 3DES, SHA-1 or a self-issued certificate cap at C; a suite without forward secrecy or without AEAD caps at B. Two findings at the same level cost one more step. A+ additionally needs TLS 1.3, TLS 1.0 and 1.1 refused, a conclusive weak-cipher probe, a chain whose signatures verify and HSTS of at least 180 days. Every cap that applied is listed under the grade.

Why is a protocol version marked "?" instead of ✓ or ✗?

The probe for that version got no usable answer: the connection could not be opened, it timed out, or it was dropped mid-handshake. That says nothing about the configuration, so it is reported as inconclusive instead of "not supported", and the grade cannot reach A+ while a legacy-version probe is inconclusive. Run the check again; a firewall that limits connection rates is the usual cause.

My server prefers ChaCha20, so why does the report show an AES-GCM suite?

The main handshake has to decrypt the TLS 1.3 Certificate message, and the WebCrypto API it runs on has no ChaCha20-Poly1305, so it offers only the AES-GCM TLS 1.3 suites. The suite shown is the one negotiated with this probe, not your server's first preference. The separate TLS 1.3-only probe offers every TLS 1.3 suite, so ChaCha20-only servers are still reported as supporting TLS 1.3.

Why does it say HSTS was not evaluated?

Strict-Transport-Security is read from one HEAD request to https://host/, and it describes the endpoint under test only when the target is a host name on port 443 and the server name (SNI) equals that host. For an IP address, another port or a different SNI the request would describe some other service, so the header is not judged and the grade stays at A at most.

Can I test a site that is served through Cloudflare?

Not from here: the check runs on Cloudflare Workers, and raw connections to Cloudflare's own addresses are blocked by the platform. Cloudflare's edge settings (minimum TLS version, TLS 1.3) are set in the SSL/TLS section of its dashboard. You can still test your origin server by entering its IP address with your host name in the Server name (SNI) field.

What does the check send to my server?

Up to six ClientHello messages, one after another, each abandoned after the server's first answer, plus one HEAD request for the HSTS header. No application data, no login, no load test. Run it only against servers you are allowed to test.

Technical notes

Every probe is a ClientHello built by the Mutqan server. The main one offers TLS 1.3 (RFC 8446) with the AES-GCM suites and TLS 1.2 and below with modern and compatible suites; the version probes each set a single version, and the TLS 1.3-only probe offers all five TLS 1.3 suites. An alert or a clean close right after the hello counts as a refusal; a failed connect, a timeout or a connection lost mid-handshake leaves the version inconclusive.

TLS 1.0 and 1.1 were deprecated by RFC 8996 in 2021, and RFC 9325 (BCP 195) asks implementations to support TLS 1.3, to prefer forward-secret AEAD suites in TLS 1.2, not to negotiate 3DES or RSA key transport, and never to negotiate RC4 (RFC 7465), NULL or export ciphers. The grade follows those rules: a negotiated or accepted RC4, NULL, EXPORT, anonymous or DES suite is F, 3DES is C, a suite without forward secrecy or AEAD is B.

HSTS is RFC 6797: the max-age directive must be a number of seconds above zero, includeSubDomains and preload are flags. The header is read from one HEAD request to https://host/ only when that request reaches the endpoint under test — a host name, port 443, SNI equal to the host.

Certificate rules come from the leaf the main handshake read: expired or not yet valid, a name the certificate does not cover, a chain link whose signature does not verify (RFC 5280 path links checked with WebCrypto), MD5 or SHA-1 signatures and RSA keys under 2048 bits. No trust store is used; a chain whose signatures all verify is described as such, never as trusted.

Limitations and methodology

The probes run from the Cloudflare data centre that serves your request, not from your network; servers that answer differently by client address or region may show another configuration to your visitors.

Sites whose names resolve to Cloudflare cannot be tested at all, because the platform refuses raw sockets to Cloudflare's own address ranges — that covers a large share of the web.

Not every suite is enumerated: the report shows the suite negotiated with this probe and the weak suites accepted, not the server's full preference list. SSL 3.0, renegotiation, OCSP stapling, session resumption and known protocol attacks are not tested.

No trust store and no revocation check: the certificate part of the grade checks dates, names, key sizes, signature hashes and that each chain link verifies, not whether a browser trusts the root.

Security and privacy

The host, port and server name go to the Mutqan server, which resolves the name, opens up to six short TLS connections and sends one HEAD request; nothing about the target or the result is stored. The probes look like an abandoned handshake to the server and may appear in its logs — test only servers you are allowed to test.

References