.avif){kind=icon}
🚀 Introducing the CloudSEK MCP Server!
Read more
An SSL scanner opens a real encrypted connection to a host and grades everything it observes: the certificate presented, the protocol versions accepted, and the cipher suites offered. It answers whether a site can be trusted by a clean client, whether the encryption behind that trust is current, and how long the certificate has left before it expires.
Pressure on that last question changed sharply during 2025 and 2026. The CA/Browser Forum approved Ballot SC-081v3 in April 2025, phasing maximum public certificate validity down from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029. Manual renewal tracking stopped being viable somewhere in that schedule, which moves the real risk from a missed reminder to renewal automation failing quietly.
How an SSL Scanner Works
Scanning is an active measurement rather than a record lookup, because the answers come from the server’s own behavior during a handshake.
- Connect to the host on the TLS port and complete a handshake, capturing the certificate the server actually presents rather than the one an inventory claims it uses.
- Build and validate the certificate chain up to a trusted root, checking that every intermediate is served and that no link is expired or revoked.
- Enumerate accepted protocol versions by attempting connections at each one, which reveals whether deprecated versions remain enabled alongside current ones.
- Enumerate cipher suites the server will negotiate, then evaluate each for known weaknesses and check the preference order the server enforces.
- Cross-reference Certificate Transparency logs for certificates issued against the domain, including any the organization never requested.
Support and enforcement are different measurements, and the distinction matters throughout. A server supporting TLS 1.3 while still accepting TLS 1.0 has not removed the risk, because an attacker able to influence negotiation will request the weaker option.
Certificate Checks an SSL Scanner Performs
The certificate is the identity document of a site, and a scanner reads every field that a browser would.
Expiry and Remaining Validity
An expired certificate is an outage rather than a warning. Every visitor meets a full-screen browser interstitial simultaneously, and API clients that validate certificates stop connecting without a human noticing. Scanners report days remaining across every discovered asset, which matters more as validity windows shorten.
Chain Completeness
A certificate has to be served with the full chain of intermediates linking it to a trusted root. Browsers paper over a missing intermediate by fetching it, and API clients and mobile applications do not, so an incomplete chain produces failures that look intermittent and browser-dependent.
Hostname and Subject Alternative Names
The certificate must cover the hostname it is serving, listed in its Subject Alternative Names field. Mismatches surface after a migration or when a wildcard certificate is stretched across names it does not cover, and each one breaks trust for a correctly configured client.
Issuer Trust and Revocation
Certificates from untrusted or self-signed authorities fail validation regardless of how strong the underlying key is. Scanners check issuer trust and revocation status through OCSP and certificate revocation lists, though most browsers soft-fail revocation checking, which is part of why the industry moved toward shorter lifetimes instead.
Shrinking Certificate Lifetimes and What They Change
Validity reduction is the most consequential operational change in certificate management in a decade, and it lands on a fixed schedule rather than as a recommendation.
Scanning practices change in two specific ways as a result. Discovery becomes more critical than tracking, because a certificate that was never inventoried can expire silently and take a service down. At the same time, the failure mode shifts from human forgetfulness to automation breakage, so scanning must confirm that renewals actually occurred rather than just that reminders were sent.
Coverage of the new schedule is narrower than most headlines suggest. The schedule governs publicly trusted certificates issued by authorities in browser root programs. Private internal PKI falls outside it, so organizations can continue issuing longer-lived certificates for internal services.
Protocol and Cipher Strength
A valid certificate can still sit on a weak connection. TLS 1.0 and 1.1 were formally deprecated by the IETF in 2021, and NIST guidance on TLS sets TLS 1.2 as the minimum acceptable version with TLS 1.3 support expected. Adoption remains incomplete: CloudSEK’s analysis of SSL misconfiguration cites Qualys SSL Pulse data putting TLS 1.3 support at 75.3% across 150,000 popular sites as of June 2025, leaving roughly a quarter of major sites on older configurations.
Enumeration applies to cipher suites exactly as it does to protocol versions. Scanners flag RC4 and 3DES outright, along with older CBC-mode constructions and any suite lacking forward secrecy. Offering a weak suite alongside strong ones provides no protection, because negotiation can be steered toward the weakest option both sides accept.
Named attacks trace back to specific weaknesses a scan detects. POODLE exploits SSLv3 padding, BEAST targets CBC ciphers in TLS 1.0, and ROBOT abuses RSA key exchange implementations. Each remains exploitable only where the underlying configuration survives, which is what makes protocol and cipher enumeration worth running rather than assuming.
Certificate Transparency Monitoring
Certificate Transparency logs record every certificate issued by a publicly trusted authority, and monitoring them answers a question no local check can: has anyone obtained a certificate for this domain that the organization never requested?
An unexpected entry signals either a certificate authority error or an active impersonation attempt, and it appears in the logs before the certificate is used against anyone. Pairing CT monitoring with a CAA record closes the loop, since the DNS record restricts which authorities can issue and the log reveals anyone who did. Certificates obtained for lookalike domains show up the same way, which makes CT logs a detection source for domain spoofing as well as for mis-issuance. Where a fraudulent certificate already serves a lookalike site, removal runs through a domain takedown request, with the wider pattern covered under brand impersonation.
Common SSL Scan Findings
Findings cluster into a predictable set, and each corresponds to either an outage or an interception risk.
Limits of SSL Scanning
Scanning measures what a server presents, which leaves several things outside its reach.
Ownership gets complicated wherever shared infrastructure is involved. Certificates served by a CDN or load balancer belong to configuration the organization does not control, so a weak protocol finding needs a provider ticket rather than an internal fix. Scanners read configuration rather than implementation, so a server with current protocols and strong ciphers can still run a library carrying a known vulnerability that only patch-level checking detects.
Everything a scan reports depends on what discovery found first. A scanner reports on the hosts it is pointed at, and the certificates that cause outages sit on assets nobody inventoried, which is why certificate monitoring works best as part of continuous external discovery rather than as a standalone check.
Best Practices for SSL Scanning
A short set of habits converts scan output into fewer outages and less interception risk.
- Discover before monitoring. Certificate tracking covers only known assets, and the silent expiries happen on hosts missing from the inventory.
- Automate issuance and renewal. ACME-based automation is the only approach that survives a 47-day validity window across a large estate.
- Verify renewals rather than reminders. Treat a failed automated renewal as an incident, since the failure mode has moved from forgetting to breaking quietly.
- Enforce TLS 1.2 as the floor. Disable SSLv3, TLS 1.0, and TLS 1.1 rather than deprioritizing them, and remove weak ciphers instead of ranking them last.
- Publish a CAA record and monitor CT logs. One restricts who can issue for the domain; the other reveals anyone who did.
- Scan continuously. Certificates move toward expiry every day, and new ones can be issued at any time, so scheduled checks leave gaps by design.
SSL Scanning with CloudSEK BeVigil
Certificates expire on their own schedule, without anyone deploying anything, which makes this a monitoring problem before it is a configuration problem. CloudSEK BeVigil runs SSL scanning as one of eight monitored surfaces, discovering internet-facing assets and the certificates serving them, then tracking expiry, testing for deprecated protocols and weak ciphers, and flagging incomplete chains.
Discovery is what separates this from a certificate checker. The platform surfaces certificate exposure across the whole estate rather than the assets a team remembers to check, which is the same reason external attack surface management treats certificates and DNS records as one exposure surface. Both layers fail together enough that assessing them separately misses the compound findings, such as a forgotten subdomain serving an expired certificate.
Final Thoughts
Certificate management used to be an annual task with a comfortable margin for error. A 200-day cap already removes the annual rhythm, and the schedule ahead compresses it further, so the practices that worked at 398 days stop working somewhere before 2029.
What survives that transition is automation paired with verification. Automated issuance handles the frequency, and continuous scanning confirms it worked, because the quiet failure of a renewal pipeline produces the same outcome as forgetting: a full-screen warning in front of every visitor at once.
Frequently Asked Questions
What is the difference between an SSL scanner and an SSL checker?
A checker tests a single host on request. A scanner discovers assets across an estate, then tests every certificate it finds, including those on hosts nobody inventoried.
Does a valid certificate mean a site is secure?
No. A certificate proves identity and enables encryption. It says nothing about protocol strength, cipher configuration, or whether the site itself is legitimate.
Why are certificate lifetimes being reduced to 47 days?
Revocation checking is unreliable because browsers soft-fail it. Shorter validity limits how long a compromised or mis-issued certificate stays usable.
Can an SSL scanner detect a certificate issued by an attacker?
Yes, through Certificate Transparency log monitoring. Any certificate from a publicly trusted authority appears in the logs, including ones the domain owner never requested.
Do the new validity rules apply to internal certificates?
No. The CA/Browser Forum schedule governs publicly trusted certificates only. Private internal PKI can continue issuing longer-lived certificates.
What does a scanner check beyond the certificate itself?
Accepted protocol versions, offered cipher suites, chain completeness, hostname coverage, revocation status, and Certificate Transparency entries for the domain.
