SSL / TLS Certificate Check

Inspect the TLS handshake, certificate chain, and supported protocols of a TLS endpoint.

TL;DR

An SSL check connects to a TLS-enabled port, completes a handshake, and reports the negotiated protocol, cipher suite, full certificate chain, expiry dates, and the host's wider TLS posture. It is how you confirm HTTPS is configured correctly and catch certificate problems before users do.

What it is

TLS (Transport Layer Security) is the cryptographic protocol that secures HTTPS, secure email, secure database connections, and almost every other "secure" variant of a protocol on the modern internet. Older versions were called SSL; the name SSL persists in casual usage even though current versions are all TLS.

A TLS check performs a real handshake and extracts: the TLS protocol version negotiated, the cipher suite chosen, the server's certificate and its issuer chain, validity dates, signature algorithm, key size, Subject Alternative Names (SANs), and OCSP stapling status.

How it works

A TLS 1.3 handshake (the current standard) looks roughly like this:

1. Client Hello: client sends supported TLS versions, cipher suites, extensions, and (for SNI) the hostname it intends to talk to
2. Server Hello: server picks a TLS version and cipher suite, sends its certificate chain, and provides key material
3. Client verification: client validates the chain against trusted CAs, checks the hostname matches a SAN, checks dates and revocation
4. Key exchange completes, both sides derive session keys
5. Encrypted application data can now flow

The check captures the handshake details and validates: was the chain complete? Was a trusted root reachable? Did the hostname match a SAN? Are any certs expired or close to expiry? Were the signature algorithm and key strength adequate?

When to use it

• Verify a certificate is valid and not about to expire
• Check the certificate covers all hostnames you serve
• Confirm a renewed certificate has actually been deployed
• Validate the TLS version and cipher suites the server supports
• Diagnose "your connection is not private" browser errors
• Audit deprecated protocol or cipher support before disabling them
• Confirm SNI is configured correctly on multi-tenant load balancers
• Inspect TLS for non-HTTPS services (SMTP STARTTLS, IMAPS, LDAPS, MySQL TLS)
• Cross-region: confirm CDNs are presenting the same certificate from every location

Running it on networktoolkit.io

Select ssl_check, enter a hostname (and optionally a port, default 443), and the check runs from each of our distributed workers. Sample output:

Target:        example.com:443
Worker:        lhr-01 (London)

TLS version:   TLS 1.3
Cipher suite:  TLS_AES_256_GCM_SHA384
Key exchange:  X25519
ALPN:          h2
SNI:           example.com
OCSP stapled:  yes (good)

Certificate (leaf):
  Subject:        CN=www.example.com
  Issuer:         CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
  Not before:     2024-01-30 00:00:00 UTC
  Not after:      2025-03-01 23:59:59 UTC
  Days remaining: 162
  Signature alg:  ecdsa-with-SHA384
  Public key:     ECDSA P-384
  SANs:           www.example.com, example.com, *.example.com
  Hostname match: yes

Chain:
  [0] CN=www.example.com  (leaf)
  [1] CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1  (intermediate)
  [2] CN=DigiCert Global Root G3  (root, trusted)

Validation: OK

Reading the results

Common scenarios

Limitations & gotchas

• A valid certificate does not mean the service is secure. TLS protects the transport; the application can still leak data, have auth flaws, or be vulnerable in other ways.
• Hostname matching is strict. A wildcard SAN like *.example.com matches one level of subdomain only. It does not match a.b.example.com or example.com itself.
• SNI is mandatory in practice. A server hosting multiple sites on one IP relies on SNI. Old clients without SNI may get the wrong certificate or fail to connect.
• Certificate Transparency logs are public. Every cert issued by a public CA is logged. Treat this as an architectural fact, not a privacy feature.
• Time-of-check is just one moment. A cert expiring tomorrow looks valid today. Always alert on time-remaining, not just on validity state.

Security & privacy notes

A TLS check is a normal, expected probe against any TLS-enabled service. It does not transmit any application data; the handshake completes and the connection closes.

Day-to-day hygiene that an SSL check helps confirm: certificates renewed well before expiry (alert at 30 days, critical at 14 days), all production hostnames covered by a SAN, TLS 1.0 and 1.1 disabled, weak ciphers (RC4, 3DES, NULL, EXPORT) disabled, the chain is complete (server sends intermediate certs).

Standards & references

• RFC 8446 — TLS Protocol Version 1.3
• RFC 5246 — TLS Protocol Version 1.2
• RFC 5280 — X.509 Certificate and CRL Profile
• RFC 6066 — TLS Extensions (defines SNI)
• RFC 6960 — OCSP
• RFC 6962 — Certificate Transparency
• RFC 8659 — DNS CAA Resource Record
• CA/Browser Forum Baseline Requirements

FAQ

What is the difference between SSL and TLS?

SSL was the original protocol; versions 2.0 and 3.0 are obsolete. TLS replaced it. The name "SSL" stuck in casual usage. Modern endpoints should use TLS 1.2 at minimum, with TLS 1.3 preferred.

Why does my browser say "your connection is not private"?

The most common causes are: expired certificate, hostname mismatch, untrusted issuer (self-signed or internal CA), or system clock wildly wrong on the client. The SSL check output will identify which.

How long should a TLS certificate be valid for?

Public CAs now issue certificates with a maximum validity of 398 days. Many automated systems issue 90-day certificates and renew them every 60. Shorter validity reduces the impact of compromise.

What is a wildcard certificate?

A certificate with a SAN like *.example.com that matches any single-label subdomain (a.example.com, b.example.com) but not deeper subdomains (a.b.example.com) and not the apex (example.com itself, unless explicitly listed).

Do I need OCSP stapling?

It is recommended. Without stapling, clients may make their own OCSP requests to the CA, which adds latency and leaks browsing patterns to the CA. With stapling, the server attaches a recent signed status from the CA to the handshake, removing the client-side query.

Why does the same domain return different certificates from different regions?

The site uses a CDN with per-region certificate provisioning, or a deployment is mid-rollout and some regions have the new cert while others still have the old.