Help Centre

Your site is likely behind Cloudflare's reverse proxy (or another CDN that terminates TLS upstream). Certprobe runs on Cloudflare Workers, and a Cloudflare Worker cannot open a direct TCP connection to a host that is itself behind Cloudflare's proxy — the platform does not allow it.

This is a platform limitation, not a finding about your server. Your certificate may be perfectly valid — you just can't reach it through Certprobe. The limitation note next to the input field on the probe page flags this.

Workaround: If your origin server has a direct hostname (one that bypasses the Cloudflare proxy), try probing that instead. Or run openssl s_client -connect yourdomain.com:443 -showcerts from a machine outside Cloudflare to inspect the chain manually.

The most likely cause is an incomplete certificate chain. The server sends the leaf certificate but omits the intermediate CA certificate. Desktop browsers have a local cache of common intermediates and may paper over the gap, but mobile browsers generally do not — they reject the connection.

Check the Chain completeness section of the probe report. If Certprobe shows only one certificate (the leaf) or flags the chain as incomplete, that's your culprit. See the question below on how to fix it.

A complete TLS certificate chain has three parts: the leaf certificate (your domain's cert), one or more intermediate CA certificates, and the root CA certificate (trust anchor). During the TLS handshake, the server should send both the leaf and the intermediate(s). The root is typically not sent because it's already in the browser's trust store.

When a server omits the intermediate, the browser must try to fetch it from a URL embedded in the certificate (the "Authority Information Access" extension). Desktop browsers often cache these; mobile browsers generally do not, and they fail the connection.

To fix it: Concatenate your leaf certificate and the intermediate CA certificate(s) into a single file, in that order (leaf first, then intermediates), and configure your web server to serve that combined file as the certificate chain. Your CA's documentation will have the exact intermediate certificate files to download.

No. Certprobe has no email sender, no scheduled checks, and no reminder system. It answers when you ask it — you paste a hostname, it probes, you get the result. That's the complete interaction.

If scheduled monitoring or expiry alerts are important to you, Certprobe is not the right tool today. Some alternatives to consider: dedicated certificate monitoring services, or a simple cron job that runs openssl s_client -connect <yourdomain>:443 and alerts you through your existing monitoring stack.

No. Certprobe checks exactly one hostname at a time — the one you type into the input field. It does not enumerate subdomains, scan IP ranges, or probe adjacent services. This is a deliberate constraint, not a missing feature: the tool is a diagnostic scalpel, not a network scanner.

A batch probe feature (paste multiple hostnames) is planned for the Pro plan, currently targeted for late 2026. No dates are guaranteed.

Certprobe opens a standard TCP connection to your server on port 443, performs a TLS handshake using the system's TLS library, and reads every certificate the server sends as part of that handshake. It then extracts the relevant fields — expiry date, issuer, subject, SANs, serial number, fingerprint — and displays them.

It is safe to use. Certprobe connects like any TLS client (a web browser, cURL, OpenSSL) would. It does not modify anything on your server, does not store any data, and discards the connection immediately after the handshake. No persistent database, no accounts, no stored results.

Note: Because Certprobe reports what the server actually presents during the handshake, the results can differ from what a browser shows after papering over chain gaps with its cache. Certprobe's report is the ground truth about what the server sent.