SSL Checker
Check a public hostname across SSL Labs endpoints for weak protocols and trust gaps, then prioritize certificate renewal and TLS fixes.{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
| Signal | State | Evidence | Copy |
|---|---|---|---|
| {{ row.signal }} | {{ row.state }} | {{ row.evidence }} |
| Endpoint | Grade | TLS / trust | Renewal / findings | Copy |
|---|---|---|---|---|
| {{ row.endpoint }} | {{ row.grade }} | {{ row.tlsTrust }} | {{ row.renewalFindings }} |
| Role | Subject / issuer | Expiry | Key / signature | Copy |
|---|---|---|---|---|
| {{ row.role }} | {{ row.subjectIssuer }} | {{ row.expiry }} | {{ row.profile }} |
| Endpoint | Trusted | Chain | Stores / note | Copy |
|---|---|---|---|---|
| {{ row.endpoint }} | {{ row.trusted }} | {{ row.chain }} | {{ row.storesNote }} |
| Priority | Finding | Evidence | Next action | Copy |
|---|---|---|---|---|
| {{ row.priority }} | {{ row.finding }} | {{ row.evidence }} | {{ row.nextAction }} |
A browser padlock confirms only that one client completed a TLS connection to one endpoint at one moment. A public hostname may resolve to several CDN or load-balancer endpoints, and those endpoints can differ in certificate chain, protocol support, trust, renewal state, or security findings. Fleet-wide posture is therefore determined by the weakest relevant endpoint, not the best result in the set.
SSL is still the familiar name for this kind of check, although modern HTTPS uses Transport Layer Security (TLS). SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 are treated as legacy protocols here. A service that offers TLS 1.3 on one endpoint but leaves TLS 1.0 enabled on another still has a deployment gap.
| Concept | What it tells you | Common mistake |
|---|---|---|
| Endpoint grade | A provider's summary of one observed endpoint | Treating the grade as a complete application-security guarantee |
| Trust path | Whether a returned certificate path is accepted by the listed stores | Assuming that a valid date alone proves client trust |
| Protocol floor | The oldest recognized protocol offered by an endpoint | Checking only the newest protocol |
| Leaf expiry | Whole days until the served leaf certificate expires | Renewing the file but not verifying what every endpoint serves |
Cached evidence is useful for a quick review, while a fresh assessment is needed after certificate, CDN, load-balancer, or TLS-policy changes. Freshness alone is not enough: DNS routing, regional edges, and staged deployments can still produce different endpoint sets. Record the hostname, assessment time, and affected endpoint with every remediation decision.
A TLS posture check is narrow by design. It can reveal trust, protocol, certificate, header, and provider-reported vulnerability signals, but it does not test application authorization, code flaws, authenticated routes, or every client platform. A strong grade should support a transport review, not end a broader security review.
How to Use This Tool:
Check the exact public DNS name clients use and choose whether recent provider evidence is sufficient for the decision.
- Enter one bare Hostname with at least two DNS labels. Omit the scheme, path, port, wildcard, IP address, and extra hostnames.
- Choose Cached review for a recent report or Fresh assessment after a deployment. Cached mode accepts a maximum report age from 1 to 168 hours; the default is 24 hours.
- Select Check SSL posture. No remote assessment begins before this explicit action, and a fresh run can take more than a minute while endpoints are tested.
- Start with the worst endpoint grade and the remediation priorities, then verify the exact endpoint, protocol floor, trust path, leaf expiry, HSTS state, OCSP stapling state, and any named vulnerability signal behind that priority.
- Run a fresh assessment after remediation and confirm that every returned endpoint now serves the intended certificate and policy.
Interpreting Results:
The headline shows the worst recognized endpoint grade, but the overall state comes from explicit risk rules. A trust gap, expired leaf, or provider-reported vulnerability makes the state critical. Legacy protocols, a leaf within the 30-day renewal window, missing HSTS, or missing OCSP stapling make it review. It is clear only when none of those conditions fires.
- Investigate endpoint differences before averaging them away; one weak edge may affect only part of the audience but still needs correction.
- Read Unknown as missing or unrecognized evidence, not as a pass.
- Confirm a certificate change with the served leaf and trust path, not only a renewed file in storage.
- Use a fresh assessment after any fix because a cached report can predate the change.
Technical Details:
The assessment source is Qualys SSL Labs API v3. Its response can contain several endpoints, certificate records, protocol lists, trust paths, HSTS and OCSP information, and named vulnerability flags. These provider fields are normalized into endpoint-level evidence before the local posture rules are applied.
Lookup Core
| Mapping | Exact order or values |
|---|---|
| Grade score | A+ 100; A 96; A- 92; B 84; C 74; D 64; E 54; F 44; T 34; M 24 |
| Protocol order | SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 |
| Legacy set | SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 |
Grade scores support ordering and the endpoint risk visualization; they do not replace SSL Labs' own grade semantics. Unrecognized grades receive no comparison score and are excluded from the chart when a numeric grade or finite expiry value is unavailable.
Formula Core
Leaf renewal timing uses the assessment time as its reference and rounds partial days upward.
A negative E is expired. Values from 0 through 30 days, including both boundaries, enter the renewal window. The display uses whole days.
Rule Core
| State | Condition |
|---|---|
| Critical | At least one endpoint has a provider vulnerability flag, no fully trusted returned path, or an expired leaf |
| Review | No critical condition, but at least one endpoint has a legacy protocol, renewal-window leaf, missing HSTS, or missing OCSP stapling |
| Clear | No critical or review condition is present in the returned evidence |
A trust path counts as trusted only when every listed trust entry in that path is trusted; an endpoint passes the trust check when at least one returned path satisfies that rule. Certificate roles are inferred from chain position and issuer relationship: the first referenced certificate is the leaf, a self-issued certificate is a root, and other records are intermediates.
Privacy and Accuracy Notes:
The submitted public hostname is sent to Qualys SSL Labs, which contacts the host and returns assessment evidence. Do not enter private names, IP literals, authenticated URLs, or confidential identifiers. The page stores no assessment until you start the check.
- Provider results are time-bounded and endpoint-specific; cached reports can precede recent changes.
- SSL Labs API v3 is the current evidence source for this page, so provider availability and schema changes can affect results.
- A provider grade and these local priority rules do not prove complete application security or universal client compatibility.
Worked Examples:
One hostname, two different edges
Suppose one endpoint returns grade A with TLS 1.2 and TLS 1.3, while another returns grade B, still offers TLS 1.0, omits HSTS and OCSP stapling, and serves a leaf that expires in 14 days. The worst grade is B and the overall state is review. The next step is to correct the second endpoint's policy and renewal deployment, then run a fresh assessment to prove that the fleet converged.
References:
- SSL Labs API Documentation v3, Qualys SSL Labs.
- RFC 8996: Deprecating TLS 1.0 and TLS 1.1, Internet Engineering Task Force, March 2021.
- How to view certificate details using OpenSSL, Simplified Guide.