Skip to content
SECQON
How it worksWhat we checkPricingSecurity
Log inStart free

SSL/TLS configuration check — what SecQon tests on your certificate and protocols

The TLS check looks at the encrypted connection your visitors make before they see a single page: whether the certificate is trusted and matches your hostname, how long it has left, and whether the server still agrees to talk in TLS 1.0 or 1.1. It runs on every scan profile, including the free instant check, and it is strictly passive — at most three TLS handshakes and nothing else.

Runs on
Light, and therefore also Standard and Deep. Runs on every plan, on the free instant check and on the Free plan’s monthly re-check.
Included from
Free plan ($0)
OWASP Top 10 (2021)
A02

What we test

Why it matters

An expired or mismatched certificate is the most visible security failure a website can have. Browsers replace your page with a full-screen warning, most visitors leave, and anything that calls your API — mobile apps, integrations, webhooks — simply fails. Certificates are usually renewed automatically, which is exactly why this breaks without anyone noticing: the renewal job stops working and nobody finds out until the day the certificate lapses. A warning at 30 and 15 days turns that outage into a routine ticket.

TLS 1.0 and 1.1 are retired protocol versions. Modern browsers no longer use them, so leaving them switched on gains you nothing, while it lets an older or misconfigured client connect with weaker cryptography. Security questionnaires and auditors ask about this directly, and “we still accept TLS 1.0” is an answer that creates follow-up questions.

Many sites sit behind a CDN or load balancer, and the TLS settings your visitors meet belong to that edge, not to your application. That is easy to overlook: we found TLS 1.0 and 1.1 still accepted on two of our own domains. The check reports what is actually answering for your hostname, so you know where the setting needs to change.

An example finding, and its fix

A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.

Medium

Deprecated TLS 1.1 is enabled

Evidence

Probe: TLS 1.1 only, SNI app.example.com, to 203.0.113.24:443
Result: handshake completed
Negotiated: TLSv1.1
Outcome: ACCEPTED

How to fix it

Find where TLS terminates for this hostname — your web server, load balancer or CDN. Set the minimum protocol version to TLS 1.2 (keep TLS 1.3 enabled). On nginx: ssl_protocols TLSv1.2 TLSv1.3; then reload. On a CDN, change the minimum TLS version in its dashboard. Re-test the finding from your report; it closes when the TLS 1.1 handshake is refused.

What we don't test

  • Cipher-suite grading. We do not rank your cipher suites; anything beyond what our known-vulnerability templates carry is not assessed.
  • Protocol versions other than TLS 1.0 and 1.1. The deprecated-version probe covers those two.
  • Your origin server when a CDN terminates TLS in front of it: we see the edge your visitors see.
  • TLS on API endpoints is not tested separately by the API check; the result here covers the host.

Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.

TLS & certificates: questions people ask

Is the TLS check safe to run against a production site?

Yes. It makes at most three TLS handshakes — one normal, one offering TLS 1.0 and one offering TLS 1.1 — and sends no requests to your application. It is part of the passive Light profile, the same set the free instant check runs.

Does SecQon grade my cipher suites?

No. The check covers certificate trust, hostname match, expiry and whether TLS 1.0 or 1.1 is accepted. It does not rank cipher suites, and the report does not imply that it did.

My site is behind Cloudflare or another CDN. Whose TLS settings are tested?

The settings of whatever answers for your hostname, which is usually the CDN edge. If the report says TLS 1.0 or 1.1 is accepted, the fix is normally the CDN’s minimum TLS version setting rather than your origin server.

When will SecQon warn me about an expiring certificate?

From 30 days before expiry (medium) and again under 15 days (high). On paid plans the daily monitoring scan includes this check, so a failed renewal shows up while there is still time to fix it.

Why does my report say the deprecated TLS versions could not be tested?

Because the probe could not get a clear answer either way — for example, the connection was cut before the server accepted or refused. We report that as unknown rather than telling you the old versions are off.

Do I need to verify my domain for the TLS check?

Not for the free instant check, which is limited to passive tests like this one. Full scans, reports and monitoring only run against assets you have proved you own.

Other checks

  • Security headers & cookies

    Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.

  • DNS & email security

    SPF, DMARC, CAA and DNSSEC — the records that stop spoofed email and mis-issued certificates.

  • Exposed ports & services

    36 high-risk TCP ports — databases, container control planes, remote admin — checked with one connect each.

  • API security

    Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.

  • Web application pentest

    A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.

Last reviewed against our scanning documentation on 24 Sep 2026.

See what a scan finds on your own asset

Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.

Start freeCompare plans