DNS Tools
TLS CONFIGURATION

TLS Checker

Check the negotiated TLS version and cipher, test TLS 1.0, 1.1, 1.2 and 1.3 separately, and read the certificate chain the server sends.

Run TLS configuration

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What this TLS checker examines

TLS protects the connection between a browser and a website. This tool reports three things. First, the session negotiated by a standard client: protocol version, cipher suite and whether the certificate was verified for the host. Second, a separate handshake offered for each of TLS 1.0, 1.1, 1.2 and 1.3, so you see exactly which versions the server accepts rather than only the best one. Third, the certificate chain the server sends, decoded into role, subject, issuer, validity dates, days left, public key type and signature algorithm.

Each version test is a controlled handshake against one address; no application data is exchanged.

How to read the protocol table

Each version is marked ACCEPTED, REFUSED or UNKNOWN.

  • ACCEPTED: the server completed a handshake with that version.
  • REFUSED: the server answered with an alert or closed the handshake, so it does not support that version.
  • UNKNOWN: this scanner could not attempt or finish the test, for example because its TLS library no longer offers the legacy version. UNKNOWN is never read as unsupported.
  • Accepting TLS 1.0 or 1.1 is flagged as an improvement because those versions are deprecated.
  • Refusing both 1.2 and 1.3 is flagged as high risk because current clients cannot connect.
  • TLS 1.2 without TLS 1.3 is informational; 1.3 is an optional modernisation.

Reading the certificate chain

The first certificate is the leaf for the host; the others are intermediates the server sends to let clients build a path to a trusted root. Check that the leaf lists your host name among its subject alternative names, that the dates are current, and that intermediates are present. Roots are normally not sent and are not assessed. Weak keys, such as RSA below 2048 bits, and obsolete signature algorithms are flagged.

The tool also shows whether Certificate Transparency timestamps are embedded and whether OCSP Must-Staple is set. OCSP stapling itself cannot be observed with this scanner's TLS library, so the result says so instead of guessing.

Common problems

  • Legacy protocols enabled: an old default configuration or a compatibility setting for ancient clients.
  • Missing intermediate: browsers may cope by fetching it, but other clients such as APIs and mail servers fail with chain errors.
  • Name not in the SANs: the certificate was issued for a different host.
  • Different servers behind one name: only one address is tested, so a load-balanced estate can be inconsistent.
  • Certificate expired or near expiry: see the expiry checker for thresholds.

How to change TLS settings safely

Prerequisites: a list of the clients that must connect, including older devices, partner systems and monitoring tools, and access to the server or load balancer configuration. Risk: disabling legacy versions stops clients that cannot use TLS 1.2. Rollback: keep a copy of the working configuration and re-enable a version if a critical client breaks while you plan its upgrade.

  1. Review access logs or load-balancer metrics for the protocol versions clients actually use, where available.
  2. Disable TLS 1.0 and 1.1 and keep TLS 1.2 and 1.3 enabled, using the vendor's current recommended cipher profile.
  3. Install the full intermediate chain together with the leaf certificate.
  4. Reload the service, then re-run this tool and check a few real clients.
  5. Keep monitoring error rates for a few days.

Limits

Protocol support is tested against one address, IPv4 first. SSLv2 and SSLv3, individual cipher suites, key-exchange groups, session resumption and known protocol vulnerabilities are not tested, so this is not a full TLS audit and does not produce a grade. Legacy handshakes use relaxed local security settings. Revocation checking is not performed.

Frequently asked questions

Does this give my site a TLS grade?

No. It reports observations without a score. A grade would need cipher and vulnerability testing that this tool does not perform.

Why is a legacy version listed as UNKNOWN?

This scanner cannot always attempt very old handshakes. UNKNOWN means untested, not unsupported.

Is TLS 1.3 required?

No. TLS 1.2 remains widely acceptable, but 1.3 is faster to establish and removes older cipher options.

Why does the chain have several certificates?

Intermediates connect your leaf certificate to a trusted root. Servers should send them.

Does this detect specific vulnerabilities?

No. It does not test for named vulnerabilities and makes no CVE claims.

Why do results differ from another tool?

Different tools offer different protocol sets, test different addresses and may check cipher suites that this one skips.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.

Written by DNS Tools editorial · Last updated 2026-10-09