Which of your subdomains are failing their SSL checks?
Discover the subdomains, then read the certificate and TLS configuration on each one — expiry, chain, protocol versions, forward secrecy — against the two Bitsight SSL risk vectors.
Check a domain
Enter the registered domain. The scan looks for subdomains in the Certificate Transparency logs and by trying names that are commonly used, keeps the ones that resolve, and completes a TLS handshake with each — the same exchange a browser performs before it loads a page.
This is the one tool here that runs on our servers rather than in your browser. There is no browser API that exposes a certificate chain, a negotiated protocol version or a cipher suite, so reading them needs a socket, and a socket needs a server. The domain you enter is resolved and connected to from our infrastructure.
This is a worked example, not your estate. It shows the shape a first scan almost always has — the main website in good order, and everything wrong sitting on the four hosts nobody has looked at since they were built. Enter a domain above to replace it.
- FSSL Certificates1 of 5 hosts clean · 5 exposed, 3 gaps
- FSSL Configurations1 of 5 hosts clean · 4 exposed, 1 gap
These letters are indicative and ours, not Bitsight's. A Bitsight vector grade is a percentile against every company Bitsight rates, normalised for size — it cannot be derived from one estate, by us or by anyone else. What the letter above shows is the share of live hosts with nothing wrong in that vector, with any exposure capping the result.
- No forward secrecy — Exposed
A static-RSA key exchange was accepted
Where the key exchange does not use ephemeral keys, anyone who records the traffic today and obtains the server key later can decrypt all of it retrospectively. That turns a future key compromise into a breach of everything already sent.
What to do: Restrict the cipher list to ECDHE and DHE suites. Every client that matters has supported them for a decade.
3 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.instatic RSA key exchange accepted; static RSA key exchange accepted; static RSA key exchange accepted - TLS 1.0 enabled — Exposed
The host still accepts TLS 1.0
Deprecated by the IETF in RFC 8996, removed from every current browser, and prohibited by PCI DSS since 2018. It is the single most common configuration finding on a forgotten host, because turning it off requires someone to decide nothing still depends on it.
What to do: Set the minimum version to TLS 1.2. Check access logs for genuinely old clients first, but expect to find none.
3 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.inTLSv1 negotiated; TLSv1 negotiated; TLSv1 negotiated - TLS 1.1 enabled — Exposed
The host still accepts TLS 1.1
Deprecated alongside TLS 1.0 in RFC 8996 and removed from browsers at the same time. It is almost always enabled by the same default that left TLS 1.0 on, and it is fixed by the same change.
What to do: Set the minimum version to TLS 1.2.
3 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.inTLSv1.1 negotiated; TLSv1.1 negotiated; TLSv1.1 negotiated - Expired certificate — Exposed
The certificate has already expired
Every browser refuses this host with an interstitial, and every API client refuses it outright. It is also the finding most likely to be sitting on a host nobody watches, because the host that mattered had monitoring and this one did not.
What to do: Reissue and deploy, then put the host into whatever renewal automation covers the rest of the estate. An expiry is rarely a one-off; it is usually a host that was never enrolled.
1 host:legacy.yourcompany.inexpired 129 days ago (2026-04-18) - Hostname mismatch — Exposed
The certificate is not valid for the name it is served on
The certificate is real but was issued for other names, so a client connecting to this hostname cannot verify it. Common on load balancers and on hosts that were renamed without reissuing.
What to do: Reissue with this hostname in the subject alternative names, or stop serving TLS on the name if it is no longer used.
1 host:webmail.yourcompany.inissued for mail.yourcompany.in - Self-signed certificate — Exposed
The certificate signs itself
No public authority vouches for it, so no client can distinguish it from one an attacker generated. Nearly always a staging or appliance host that was stood up quickly and then became load-bearing.
What to do: Issue a certificate from a publicly trusted authority. If the host is genuinely internal, take it off the public internet rather than leaving it reachable with a certificate nobody can verify.
1 host:uat.yourcompany.inissuer equals subject (uat.yourcompany.in) - Weak Diffie-Hellman group — Exposed
The key exchange uses an undersized DH group
A finite-field group below 2048 bits is within reach of precomputation against the group, which is the attack described in the Logjam research: break the group once, then read every session that used it cheaply.
What to do: Generate a 2048-bit or larger group, or move to ECDHE and stop offering finite-field DH.
1 host:vpn.yourcompany.in1024-bit DH group - Weak public key — Exposed
The key is below the accepted minimum
RSA under 2048 bits and elliptic curves under 256 bits are below the floor every authority and every browser now enforces. A key this size is a factoring problem rather than a cryptographic one.
What to do: Reissue with a 2048-bit RSA key at minimum, or a P-256 key. Generate a new key rather than reusing the old one.
1 host:uat.yourcompany.inRSA 1024 bits - Weak signature algorithm — Exposed
The certificate is signed with a broken hash
SHA-1 and MD5 collisions are practical and have been demonstrated against real certificates. A chain signed this way cannot be relied on to prove anything about who issued it.
What to do: Reissue with SHA-256 or better. Check the intermediates too — a modern leaf on a SHA-1 intermediate is a chain that still fails.
1 host:uat.yourcompany.insha1WithRSAEncryption (leaf) - No OCSP stapling — Gap
The server does not staple a revocation proof
Without stapling, a client that wants to know whether this certificate was revoked has to ask the authority directly — which most clients no longer do, because it is slow and it leaks browsing to the CA. In practice revocation stops working. This is not a statement that the certificate is revoked; the probe does not check that.
What to do: Turn on OCSP stapling at the server or terminator. It is one directive on every mainstream web server and it costs nothing at runtime.
4 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.in, webmail.yourcompany.inno CertificateStatus in the handshake; no CertificateStatus in the handshake; no CertificateStatus in the handshake - No TLS 1.3 — Gap
The host does not offer TLS 1.3
Not a vulnerability — TLS 1.2 correctly configured is still sound. It is a gap because TLS 1.3 removes the negotiation of everything that has gone wrong historically, so a host without it depends on the rest of its configuration being right.
What to do: Enable TLS 1.3 alongside 1.2. On current server software this is a version bump rather than a configuration change.
4 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.in, webmail.yourcompany.inbest offered: TLS 1.2; best offered: TLS 1.2; best offered: TLS 1.2 - Incomplete chain — Gap
The server does not send its intermediate certificates
Browsers usually paper over this by fetching the missing intermediate themselves, which is why it survives so long unnoticed. Anything that does not — mobile apps, Java clients, API integrations, and most rating scanners — sees an unverifiable certificate.
What to do: Serve the full chain: leaf, then every intermediate, in order. This is a server configuration change, not a reissue.
1 host:webmail.yourcompany.inserver sent 1 certificate - Validity period too long — Gap
The certificate is valid for longer than the rules allow
Publicly trusted certificates have been capped at 398 days since September 2020, and the cap is falling further. A longer period means the certificate predates the rule or did not come from a public authority — and it lengthens the window in which a stolen key stays useful.
What to do: Reissue within the current maximum and shorten the renewal cycle. Anything issued for years at a time is a key you cannot rotate quickly.
1 host:uat.yourcompany.in3650 days (2023-02-01 to 2033-01-29) - RC4, 3DES, EXPORT and SSLv3 — Not tested
This probe cannot test the oldest ciphers, and does not claim to
OpenSSL 3 removes RC4, 3DES, EXPORT-grade suites and SSLv3 from its default provider, so this scanner cannot offer them — the handshake fails on our side before anything reaches your server. That means silence here is not evidence of absence. It is reported rather than omitted because a scanner that quietly skips a check reports a clean result it has not earned.
What to do: A host with TLS 1.0 or 1.1 enabled is very likely to accept these too. Assume so until an on-host cipher list says otherwise; disabling the old protocols usually removes them at the same time.
5 hosts:legacy.yourcompany.in, uat.yourcompany.in, vpn.yourcompany.in, webmail.yourcompany.in, www.yourcompany.inOpenSSL 3 does not provide these suites to the client
A clean result here is the absence of one class of finding, never a verdict on your security. This reads two risk vectors on the hosts it could find; a security rating is calculated from several hundred signals across an entire external estate.
Why the estate, not the host
A security rating is calculated across every host attributed to the company, not the one whose certificate somebody remembers to renew. That asymmetry is the whole reason this tool discovers before it checks.
The main website is almost always in good order. It has monitoring, it has an owner, and its certificate renews itself. The findings that cost a rating sit somewhere quieter: a VPN appliance that still accepts TLS 1.0 because turning it off needed someone to confirm nothing depended on it, a UAT box stood up with a self-signed certificate that quietly became load-bearing, a webmail host serving only its leaf certificate because the browser papers over the missing intermediate and nobody has ever complained.
The two vectors this feeds
Bitsight treats these as two separate risk vectors, and a host can fail one while passing the other cleanly.
- SSL Certificates is about the certificate itself — whether it has expired, whether it covers the hostname it is served on, whether its chain leads to a trusted root, how it is signed and how strong its key is.
- SSL Configurations is about the negotiation — which protocol versions the server will accept, which cipher suites it will agree to, and whether the key exchange gives forward secrecy.
Both sit in the Diligence category, and both are covered by Dynamic Remediation: the on-demand rescan that lets an organisation claim credit for a fix rather than waiting for the next observation. The five vectors it covers are SSL configurations, SSL certificates, open TCP ports, server software and web application security. That makes TLS work unusually good value — it is configuration rather than architecture, and the credit arrives on request.
Bitsight reports each vector as a letter grade, which is a percentile against every company it rates, normalised for size. The letters this tool shows are not that, and it says so on the result: a percentile against an inventory of hundreds of thousands of companies cannot be derived from one estate. What it shows instead is the share of your live hosts with nothing wrong in each vector, so the arithmetic is yours to check.
What this probe cannot test
Four checks a paid scanner would run are missing here, and the report labels them not tested rather than passing them silently. A scanner that skips a check and reports a clean result has told you something worse than nothing.
- RC4, 3DES, EXPORT-grade ciphers and SSLv3. OpenSSL 3 removed them from its default provider, so this scanner cannot offer them — the handshake fails on our side before anything reaches your server. Tested against hosts that do accept those ciphers, and they answer a handshake failure all the same. A host still accepting TLS 1.0 is very likely to accept them too.
- Revocation. The scan reports whether a server staples a proof of freshness, which is a different question from whether the certificate has been revoked. Answering that needs a call to the issuing authority for every certificate.
- Anything on a port other than 443, and anything that needs a payload rather than a handshake. The probe observes what a server volunteers and never acts on it, which is the same boundary we hold in client engagements.
- Hosts that appear in no public log. Certificate Transparency records publicly trusted certificates, so a host with a private certificate and an unguessable name is invisible to it and to the name list. Discovery here is a floor, not an inventory.
The last of these is the reason a clean result is worth less than a dirty one. A finding is evidence; an absence of findings is evidence only about the hosts that were found.
The order worth fixing them in
Not the order the findings are listed in, which is by severity. The order below is by what clears the most for the least work.
- Protocol versions first. Setting a minimum of TLS 1.2 on one host usually clears three findings at once — TLS 1.0, TLS 1.1, and often the weak cipher suites that only those versions offered. Check access logs for genuinely old clients first; on an internet-facing host you will usually find none, and where you do it is a partner integration or a payment terminal rather than a browser.
- Certificates second. Each one is its own reissue and its own deployment, so they parallelise across teams in a way the protocol change does not. An expiry is rarely a one-off — it is almost always a host that was never enrolled in whatever renews the others.
- Chain completeness with them. Serving the intermediates is a server configuration change rather than a reissue, and it is the finding most likely to be invisible to you and visible to everyone integrating with you.
- Stapling last. One directive, no client will notice the day it lands, and nothing else depends on it — which is exactly what makes it the safe thing to defer.
The Rating Report is where the actual vector grades come from, alongside the rest of the estate this tool does not look at — open ports, server software, patching cadence and the credentials circulating about your people. It is complimentary and takes 48 hours.
Every instrument cited here was verified against the issuing regulator's own notification on .Questions this page answers
- How do I check the SSL certificate on all my subdomains at once?
- You need the list of subdomains before you can check anything, and that is the part most tools skip. Certificate Transparency logs record every publicly trusted certificate ever issued, so they name hosts you may have forgotten — and probing common hostnames finds the appliances that never had a public certificate at all. This tool does both, then runs a TLS handshake against each host that resolves.
- What does Bitsight look at for SSL configurations and SSL certificates?
- They are two separate risk vectors. SSL Certificates covers the certificate itself — whether it has expired, whether it matches the hostname, whether the chain leads to a trusted root, how it is signed and how strong its key is. SSL Configurations covers the negotiation — which protocol versions the server accepts, which cipher suites it will agree to, and whether the key exchange provides forward secrecy. A host can fail one and pass the other.
- Does fixing an SSL finding improve a Bitsight rating quickly?
- Faster than most findings, because both SSL vectors are covered by Dynamic Remediation — the on-demand rescan that lets an organisation claim credit for a fix rather than waiting for the next observation. The five vectors it covers are SSL configurations, SSL certificates, open TCP ports, server software and web application security. A certificate or protocol change is also among the cheapest fixes there is: it is configuration, not architecture.
- Is a scan like this intrusive, and do I need permission?
- The probe completes a TLS handshake on port 443 and reads what the server volunteers — the same exchange every browser performs before loading a page. It sends no payloads, tests no vulnerabilities and touches no other port. We still ask you to confirm you own or are authorised to test the domain, because the sensible boundary for a scanner is the one its operator would be comfortable explaining afterwards.
- Why does the report say some checks were not tested?
- Because they were not, and saying so is more useful than a clean result that has not been earned. RC4, 3DES, EXPORT-grade ciphers and SSLv3 were removed from OpenSSL 3, which this scanner runs on, so it cannot offer them — the handshake fails on our side before anything reaches your server. A host still accepting TLS 1.0 is very likely to accept those ciphers too, and disabling the old protocols usually removes them together.
- Does a clean result here mean our external security is fine?
- It means one class of finding is absent from the hosts this probe could find. Subdomain discovery is a floor rather than an inventory — a host with a private certificate and an unguessable name appears in no public log. And a security rating is calculated from several hundred signals across an entire external estate: patching, exposed services, endpoint hygiene, credentials on underground markets. TLS is two risk vectors inside that.