CheckSSL.dev
Tools

Maker, method & scope

About CheckSSL.dev

CheckSSL checks a hostname’s TLS connection on port 443, inspects the received certificates and attempts limited protocol, CAA and certificate-revocation checks.

Made by Koen Schipper

CheckSSL.dev is made by Koen Schipper, an independent Laravel developer. It is part of the same collection as HeaderScan, RedirectPath, CheckSSL and SiteAudit: focused tools for understanding a public website’s technical behavior.

The aim is to connect an observed result with a useful next step. Findings include evidence, explanations and links to practical guides so you can decide whether a change fits your website.

About Koen Schipper and his work (opens in a new tab)

How a scan works

  1. Resolve the hostname to public addresses and connect to one address using the original hostname for SNI and certificate verification.
  2. Record the verification result, received certificate chain, validity dates and negotiated connection details. If verification fails, a separate diagnostic attempt may retrieve untrusted certificate details.
  3. When certificate details are available, attempt TLS-version probes and CAA lookup; attempt a signed leaf-certificate CRL check when the connection is trusted.

Explore a fixed example using the same report layout

What is checked

  • Checks connection trust and hostname verification using the scanner’s TLS runtime and trust configuration, and reports certificate validity and expiry.
  • Shows selected certificate details, public certificate PEM data, received chain order, public-key baseline checks and signature-algorithm findings.
  • Reports the negotiated TLS version and cipher, plus limited support probes for TLS 1.0, 1.1, 1.2 and 1.3 against the same connected address.
  • Looks for CAA records through bounded alias and parent-domain lookups. Finding records does not establish that a certificate authority will issue or renew a certificate.
  • Attempts to verify the server certificate against a current signed CRL. It also reports embedded certificate-transparency information when present.

Limits of the result

  • Uses a 20-second total budget with separate limits for the initial handshake, protocol probes, DNS lookups and CRL downloads. Unfinished or inconclusive checks remain unknown.
  • Checks the supplied hostname on port 443 only. It does not follow website redirects, test every resolved address or inspect other hostnames and ports.
  • Diagnostic handshakes and protocol probes do not establish certificate trust. A protocol is marked unsupported only for a recognized protocol-version rejection; other failures can remain unknown.
  • Does not exhaustively enumerate cipher suites or test every browser’s trust policy. Received certificates are not necessarily the complete trust path built by a client.
  • Does not check OCSP, intermediate-certificate revocation, CT log signatures or full browser CT compliance. A missing or unavailable CRL is not proof that the certificate is unrevoked.

A result describes one measurement from this scanner. It is not a security certification, a complete website audit or a promise of search visibility. “Unknown” means the check could not establish a result; it is different from a confirmed failure.

Understanding scores

The numeric score covers connection and trust for 50 points, hostname verification for 25 and validity for 25. Expiry within 30 days earns 15 validity points; an expired or not-yet-valid certificate earns none. Required evidence must be available before a score is shown.

Additional findings can change the report status without changing those score weights. A verified revocation, weak assessed key or obsolete signature can produce a failure; confirmed TLS 1.0 or 1.1 support can produce a warning. Read these findings alongside the number.

The 30-day expiry threshold is a reminder to check renewal and deployment, not proof that automatic renewal has failed. The report is a point-in-time observation, not certificate monitoring or a guarantee of compatibility.

Read the finding and its evidence before changing a setting. Verify the deployed change with a new scan and a relevant independent check; a higher score alone does not establish that a website meets its requirements.

Report data & sharing

No account is required. Scan reports are public: anyone who knows the result URL can open them. The URL is based on the hostname and tool and shows the latest available scan for that host. A later scan, including a different path on the same host, can change the displayed report.

Reports expire after seven days and are eligible for daily cleanup. Live report pages ask search engines not to index them; this is not access control. The fixed example reports are separate public pages with fictional data and do not expire.

Stored reports contain selected findings and redacted evidence, not the full HTML, robots.txt or sitemap bodies. Query values in submitted and captured HTTP URLs and sensitive or unrecognized response-header values are masked. Hostnames, URL paths, query parameter names, connected IPs, selected metadata and public certificate details may remain visible. Do not submit confidential URLs or treat redaction as a guarantee that every secret will be recognized.

The scan runs from the server against the public target. It does not receive your browser’s signed-in session. Requests can appear in the target server’s logs.

Guides & corrections

The guides use AI-assisted research and drafting, with practical examples, verification steps and links to primary documentation. Scanner-specific explanations describe the implemented checks and their limits. Example values and configuration snippets need to be adapted to your own application.

If a result or explanation seems wrong, include the tool, the relevant finding and the expected behavior when reporting it. Remove credentials and confidential information from any example you send. A report URL can change or expire, so include the relevant observation as well.

Contact Koen Schipper about a correction (opens in a new tab)

How the tools are funded

Reports and guides may include a clearly labeled Cloudways affiliate link. If you follow that link and become a paying customer, we may earn a commission that helps support these tools.

Using the scanners and guides does not require a hosting purchase. Affiliate placements do not change the checks, scores or technical advice. Compare a provider’s features with your requirements; choosing a host does not by itself resolve a finding.