Connection evidence / one hostname
SSL Certificate Checker
Inspect one public hostname's TLS connection and the certificate evidence available from that endpoint. Review connection verification, certificate dates, names and the presented chain in a focused report.
Enter a hostname or explore a clearly labeled demo. Download the report as JSON or CSV when you need to keep the observation and its limitations together.
One hostname.
Clear connection evidence.
Start with the exact service name. Review the verification outcome first, then inspect the available certificate dates, names and presented chain.
What this endpoint presents.
Connection & verification
Leaf certificate
Certificate names
Names are certificate metadata. Their presence alone does not establish a verified connection.
Presented certificate chain
Evidence notes & limitations
This is a summary. The JSON and CSV downloads retain the structured certificate evidence.
This check connects to one public IPv4 address for your hostname on port 443. It does not fetch an HTTP page, scan every address, check certificate revocation, or provide an SSL Labs grade. A connection failure leaves certificate status unknown. Results reflect this checker’s connection and trust store at the time shown; no visitor account or saved history is created.
Check the hostname you intend to investigate
Enter a hostname such as example.com or www.example.com. Leave out https://, paths, port numbers and IP addresses. International domain names are supported.
The hostname matters. The apex domain and a www subdomain can have different DNS records, endpoints or certificate deployments. Check the specific name associated with the problem.
Complete human verification, then select Check certificate. Reset clears the input and displayed report so you can start another review.
This release uses one public IPv4 endpoint on port 443. An IPv6-only service, alternate port or another address for the same hostname is outside that observation.
02 / A report you can inspect
What appears in the report
| Area | Evidence to review |
|---|---|
| Connection | Outcome, selected endpoint, elapsed time, backend context and result code. |
| Verification | Peer and hostname verification for this connection, using the checker's trust configuration. |
| Certificate dates | Available not-before and not-after values, with the date state at the recorded observation time. |
| Identity metadata | Subject, issuer and retained certificate names. |
| Certificate details | Available serial number, SHA-256 fingerprint, signature algorithm and public-key details. |
| Presented chain | Retained certificates supplied by the endpoint, with their positions and available metadata. |
| Coverage | Addresses tested, other resolved addresses not tested, unavailable fields and limitations. |
A field may be unavailable when the connection fails or metadata cannot be obtained. Read the evidence context before treating a blank field as an absent certificate property.
03 / Start with the connection
Read the outcome.
Then review the detail.
The connection, certificate fields and date window answer different questions.
Read the connection outcome first
A verified result means this connection passed peer and hostname verification against the checker's trust configuration at the recorded time.
That is useful evidence for one endpoint and one client configuration. It does not certify every browser, device, CDN edge or address associated with the hostname.
A timeout or network failure leaves the certificate's status unknown. It does not, by itself, prove that the certificate expired, has the wrong name or is untrusted.
Use the report's outcome and available details to decide which question to investigate next. Do not replace missing evidence with an assumed certificate failure.
Keep verification and metadata separate
A certificate can contain a familiar domain name, an issuer name and plausible dates without establishing a trusted connection. These are metadata fields; the verification outcome addresses a separate question.
Similarly, a certificate that is currently within its leaf date window can still present another verification problem. Date validity is useful, but it is not a complete trust decision.
Read the evidence context associated with the leaf certificate. It explains where the available metadata came from.
If a colleague reports a different result, compare the hostname, endpoint, observation time and client trust environment before assuming either observation describes every visitor.
Review expiry in UTC and at the recorded time
The not-before value marks the start of the certificate's stated date window. The not-after value marks its end. Read both alongside the report's observation time.
A saved report describes an earlier observation. A certificate can be renewed or replaced after that report, and a previously valid date window can later expire.
Use the expiry value to plan the next administrative action. Confirm that the intended replacement has actually been deployed to the relevant service rather than assuming successful renewal automatically updated every endpoint.
The report is a point-in-time check. It does not create reminders, renew certificates or monitor the hostname in the background.
A prepared example
Use the fabricated demo to learn the layout
Explore a demo report displays invented connection, address and certificate information. It does not look up or contact the example hostname.
The fabricated demo uses:
| Demo field | Invented value |
|---|---|
| Hostname | example.com |
| Observation time | 18 September 2026, 10:00 UTC |
| Endpoint | 192.0.2.10:443 |
| Addresses tested / not tested | 1 / 1 |
| Connection verification | Passed in the fabricated example |
| Leaf date window | 1 September–1 December 2026 |
| Retained names | example.com and www.example.com |
The example's documentation address, issuer, fingerprint and other certificate details are also fabricated. They are not evidence about example.com's real deployment.
Demo downloads retain the fabricated-data marker. Keep that marker when showing the report to someone else so it cannot be mistaken for a live check.
04 / Know what the fields mean
Identity, dates
and evidence.
Understand certificate names
The subject field can include a Common Name and organization text. Subject Alternative Names can list the identities described by a certificate.
Read the listed names as certificate metadata. Their presence alone does not establish a verified hostname match, ownership of a business or the safety of the website's content.
Wildcard names also require careful interpretation. A wildcard's presence is not a promise that every possible subdomain or the apex is covered.
The report retains a bounded number of names, with a retention limit of 50. Read truncation or unavailable notices before treating a displayed list as complete.
Hostname verification depends on the actual client policy and backend. Use the report's verification result and context rather than manually declaring a match from one familiar-looking name.
Read the presented chain accurately
The chain section shows retained certificates presented by the endpoint, with their positions and available fields. The leaf is the certificate associated with the service being checked.
A server-presented list and a successfully constructed trust path are different evidence. Clients can have different roots, intermediate handling and policy.
The absence of a root from the server's presented list does not automatically mean the installation is incomplete. Trust anchors commonly come from the client environment.
If the chain appears unexpected, compare the server configuration, relevant intermediate certificates and the client trust environment. Do not install arbitrary certificate files simply because an issuer name looks related.
Use fingerprints and algorithms for identification
A SHA-256 fingerprint helps identify a particular certificate. A change can reflect a legitimate renewal or replacement, so compare it with the intended deployment and observation time.
The serial number is another certificate identifier, interpreted in its issuer context. It is not a website trust score.
The certificate's signature algorithm and public-key details describe certificate material. They are not an exhaustive list of negotiated TLS protocols, supported cipher suites or vulnerabilities.
Use these fields to support a specific comparison or configuration investigation. A familiar algorithm name or key size alone is not a complete security verdict.
05 / Follow the evidence
Choose the next question
with a clear scope.
One endpoint can differ from another
A hostname can resolve to several addresses or route visitors to different infrastructure. This checker selects one public IPv4 endpoint and reports the scope of that connection.
Another address, IPv6 service or regional edge may present different evidence. A successful result for one endpoint does not establish deployment consistency everywhere.
When a problem affects only some visitors, retain their relevant environment and timing information and investigate the deployment responsible for those connections.
Multiple-address testing is outside this release's scope. The report's count of other resolved addresses is a coverage notice, not a claim that those addresses passed or failed.
A TLS connection check does not fetch the page
This checker does not request an HTTP page. It therefore does not inspect response headers, redirects, page content, mixed resources or login behavior.
A browser page can have issues beyond certificate acceptance. For example, an HTTPS page can request HTTP resources, or a migration can leave old links and unexpected destinations.
Use the Redirect Checker to investigate the current HTTP redirect path. Use the Broken Link Finder for relevant page-link failures under its separate workflow.
These checks add different evidence. A certificate result alone cannot explain every problem encountered while browsing.
Review the page after resolving connection questions
Once you can assess the intended connection, use the SEO Checker for a review of one page's returned HTML.
If the concern is technical indexing signals, continue with the Indexability Checker. For a preferred-URL declaration, use the Canonical Tag Checker.
The certificate's hostname, a page's canonical declaration and Google's indexing decision are related to different parts of the investigation.
Do not interpret a verified TLS connection as proof that Google indexed the page, selected the intended canonical or will rank it for a particular query.
Revocation, transparency and renewal are separate workflows
This release does not perform certificate-revocation lookups. A connection result without a revocation check is not evidence that a certificate has never been revoked.
Certificate Transparency searches can reveal logged issuance information. They do not by themselves prove which certificate this endpoint currently presents.
Renewal or issuance tools manage another stage of the lifecycle. This checker does not request, install or replace a certificate.
Choose the appropriate workflow for the question, and keep its source, time and scope attached to the resulting evidence.
06 / Keep the context attached
An observation you can
review and share.
Export a bounded observation
JSON preserves structured report fields. CSV organizes report and certificate evidence into rows that can be reviewed in a compatible application.
The fabricated demo CSV contains a report row, a leaf row and a presented-certificate row. The leaf appears in both roles because the presented list includes it; those rows do not represent two different certificates.
Exports retain the demo label when applicable, observation context, limitations and unknown fields. Preserve those details when sharing a report.
Open the completed file and check that it describes the intended hostname and run. A missing value is not automatically zero, false or a successful check.
Timing, availability and controls
The TLS connection has a configurable timeout, with an eight-second default. DNS resolution and local processing can add time, so that is not a guarantee that the whole interaction completes within eight seconds.
A slow or failed request is an observation from this checker's environment. It does not establish a worldwide outage.
Human-verification codes are single use and expire after ten minutes. The administrator can disable checks, change the timeout, control exports and assign the tool page.
Read current interface messages when a check is unavailable. Do not substitute the demo for live evidence; it is available to explain the report, not to diagnose a submitted hostname.
Privacy and saved reports
This module does not create visitor accounts, save visitor reports or schedule recurring jobs.
Shared security and usage counters and ordinary server logs can still exist. The absence of a saved visitor report is not a promise that the entire site keeps no operational records.
Submit public hostnames you are permitted to investigate. DNS and connection activity can disclose the requested hostname to the services involved.
A downloaded report remains a file you control. Review its hostname, endpoint and runtime details before distributing it, and keep invented examples clearly marked.
A practical review sequence
Confirm the exact hostname and service first. Run the check, read the connection outcome and identify which endpoint was tested.
Review available dates, names and chain evidence in that context. If information is missing, record the uncertainty rather than supplying an assumed cause.
Coordinate any repair with the person responsible for the certificate, proxy, CDN or server. After a change, check the intended endpoint again and investigate broader coverage when needed.
Use the SEO and Content Tools hub for a focused next step. Keep certificate observations separate from page, indexing and campaign conclusions.
Questions before you check
SSL Certificate Checker FAQs
Is SSL the same term as TLS here?
SSL is the familiar search term used for certificate checks. Modern secure connections use TLS. This report concerns the TLS connection and available certificate evidence described above.
Does a verified result mean the whole website is secure?
It describes this one connection under this checker's trust configuration. It does not assess every page, application issue, address, client or security control.
Does a timeout mean my certificate is invalid?
No. A timeout or network failure can leave certificate status unknown. Investigate connectivity and available verification evidence before assigning a cause.
Is expiry the same as revocation?
No. Expiry concerns the certificate's stated date window. Revocation is a separate status question, and this release does not perform those lookups.
Does an expired certificate prove traffic became plaintext?
No. Expiry can prevent clients from accepting the connection. The date alone does not establish that requests were sent over HTTP.
Can I check another port or an IP address directly?
The current input is a public hostname, and the documented connection uses one public IPv4 endpoint on port 443. Other ports and IP-literal input are outside that contract.
Why can a browser and this checker disagree?
They can use different trust configuration, endpoints, network paths or observation times. Compare the relevant evidence rather than treating one result as universal.
Does this tool provide an SSL Labs grade?
No. It does not perform an exhaustive protocol/cipher or vulnerability assessment and does not generate that grade.
When a connection issue is part of a larger access or migration problem, SEO audit services can help scope the affected pages and next actions.
For a useful page ready for promotion, compare guest-post publisher options against topic, audience, market and approved placement requirements. A certificate check does not qualify a publisher or predict campaign results.
Dofollow and Google indexing commitments apply to confirmed placements where specified in the approved order. They are separate from this free connection observation.