Cidvise
TLS checker

TLS checker: see which protocols and ciphers your server still accepts

See what your server accepts to negotiate: protocol versions, cipher suites, forward secrecy and known flaws such as Heartbleed and ROBOT. Results on screen in seconds and a full PDF.

Accepts a domain or subdomain, such as app.yourcompany.com. Each address is scanned separately.

No sign-up to see the resultResult in ~40 secondsPassive external scan
or scan a single area
HTTP headers scanEmail scan (SPF, DKIM, DMARC)Full security scan
What is analyzed

What a TLS connection negotiates, and what this scan records

ClientServer
1. ClientHelloTLS versions and ciphers the client supports
2. ServerHello + Certificatechosen version and cipher, certificate chain
3. Key exchangesession secret: RSA, or ECDHE/DHE with an ephemeral key
encrypted session with the parameters chosen by the server

Every HTTPS connection starts with a handshake. The client lists the TLS versions and cipher suites it supports. The server picks a combination among the ones it accepts and presents its certificate. The strength of the session encryption is decided in that choice, and the choice depends on what the server is configured to accept.

The certificate only covers identity: it proves the server is who it claims to be. It does not set the protocol version, the key exchange algorithm or the cipher suite. A server with a valid certificate can accept TLS 1.0, negotiate RSA key exchange and keep TLS compression enabled. None of these conditions shows up in the browser.

How the scan measures. It runs successive handshakes, offering one specific version or cipher at a time, and records what the server accepts. That answers three questions: which protocol versions are enabled, which cipher suites can be negotiated and whether the key exchange generates an ephemeral key per session, which is what defines Perfect Forward Secrecy. It also checks TLS compression, secure renegotiation, TLS_FALLBACK_SCSV support and the response to Heartbleed and ROBOT probes.

The analysis uses the same engine as cidguard, built on sslyze. Each finding comes with severity, evidence of what was negotiated and remediation steps. The terms in the result are explained in the glossary.

Checks

What the scan looks for

Four groups of checks. Each one observes a stage of the handshake and records the parameter the server accepted.
01

Enabled protocols

SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 were deprecated by the IETF. As long as the server accepts one of these versions, any client can negotiate it. PCI DSS records an accepted legacy version as non-compliance.
RFC 6176RFC 7568RFC 8996PCI DSS 4.0
02

Key exchange and forward secrecy

Ciphers with RSA key exchange derive the session key from the certificate private key. If that key leaks, traffic captured in the past can be decrypted. With ECDHE or DHE, each session uses an ephemeral key, and a leaked certificate does not compromise earlier sessions.
RFC 8446 搂4.2.7NIST SP 800-52r2
03

Downgrade, renegotiation and compression

TLS_FALLBACK_SCSV prevents an intermediary from forcing the connection to a lower version. Insecure renegotiation allows data injection at the start of the session. Enabled TLS compression exposes the connection to the CRIME attack.
RFC 7507CVE-2009-3555CVE-2012-4929
04

Heartbleed and ROBOT

Heartbleed lets an attacker read blocks of server memory through the heartbeat extension. ROBOT exploits RSA key exchange with PKCS#1 v1.5 padding to decrypt sessions. Both are checked with detection probes, without extracting data.
CVE-2014-0160CVE-2017-13099
How it works

From domain to report

The domain is all we need. The scan runs on the host you enter, the score shows up on screen and the full report is sent by email.
10 s

Enter the domain

Just the domain. No account, no credit card and nothing to install.

20 s to 40 s

The scan runs

The same scanner the platform uses runs against the host, in real time.

3~40 s

The score shows up

A score from 0 to 100, calculated with the product formula, with the most severe findings shown.

4After confirming your email

The report arrives by email

Full PDF with evidence and remediation steps, sent to an email address at the scanned domain.

Sample result
acme.comscore71C
TLS3 findingsTLS 1.0 accepted 路 4 ciphers without PFS 路 TLS_FALLBACK_SCSV missing
PDF report sent to an email address at acme.com
Delivery rule

Why only an email at the scanned domain. The report describes weaknesses of a specific domain. Sending it to any address would let third parties obtain this assessment without any relationship to the domain. If you do not have an email at the domain, contact us and we will send the report once your relationship with it is confirmed.

Scope

What the scan does on the target

Contact with the target is limited to what any client does when accessing the domain. Anything that requires authorization from the owner of the environment is left out.
In scope

Open TLS connections to the host

Successive handshakes, each offering one protocol version or cipher suite, to record what the server accepts.

Read the certificate chain

The chain presented in the handshake is recorded, including issuer, validity and signature algorithm.

Send detection probes

Heartbleed and ROBOT are checked by how the server responds to test messages, without extracting data.

Query DNS and the home page

SPF, DKIM and DMARC records and the home page HTTP headers are part of the full security scan, with findings separated by check.

Out of scope

Probe ports and services

Port scanning reaches infrastructure that may belong to the provider, as with PaaS and CDNs. This kind of test requires formal authorization from the owner of the environment.

Enumerate paths

There is no attempt to discover routes such as /admin or /.env through wordlists. That procedure generates request volume on the target and only runs with authorization.

Exploit vulnerabilities

No payload is sent and no vulnerability is exploited. Probes observe how the server responds, without extracting data.

Cover the full inventory

The result covers the domain you enter. Subdomains, staging environments and auxiliary services are part of the full platform analysis.

FAQ

Frequently asked questions

What is TLS posture?

It is the set of parameters the server accepts to negotiate in a TLS connection: protocol versions, cipher suites, key exchange algorithm, extensions and protections. The certificate is one of those parameters, but the posture includes all the others. Two servers with the same valid certificate can have very different postures.

Does the scan check the certificate?

The scan analyzes the full handshake, including the certificate chain the server presents. The focus is on the parameters the browser does not show: accepted protocol versions, negotiable ciphers, key exchange with forward secrecy, TLS compression, secure renegotiation and the response to Heartbleed and ROBOT probes.

What is Perfect Forward Secrecy and why does it matter?

Perfect Forward Secrecy is the property of a session whose key cannot be recovered from the server private key. It exists when the key exchange uses ECDHE or DHE, which generate an ephemeral secret per session. Without PFS, anyone who captured traffic and later obtains the private key can decrypt every recorded session. With PFS, the private key only authenticates the server.

Is accepting TLS 1.0 or TLS 1.1 still a problem?

Yes. Both versions were deprecated by RFC 8996 in 2021 and rely on constructions with documented weaknesses, such as the TLS 1.0 CBC mode exploited by BEAST. PCI DSS requires TLS 1.2 or higher for cardholder data in transit. If the server keeps the version for compatibility with a specific client, the finding still applies, because any client can negotiate that version while it is enabled.

Is the scan intrusive? Does the server log anything?

The scan opens TLS connections and observes what the server accepts to negotiate. In the server log they appear as TLS connections, the same kind any HTTPS client generates. No payload is sent, nothing is exploited and no ports are scanned. Heartbleed and ROBOT are checked with probes that observe how the server responds, without extracting data.

Does the score on this page include email and HTTP headers?

No. This page runs only the TLS scan, and the score reflects that result. The full security scan runs TLS, HTTP headers and email on the domain you enter, and each finding shows which check it came from.

How often should I run the test again?

TLS configuration changes when you switch CDN, load balancer or hosting provider and when certificates are renewed, moments when the server may fall back to provider defaults. The definition of secure also changes: ciphers accepted today end up on deprecation lists later. A one-time test describes the current state. The platform repeats the check every 35 days and records how it evolves.