Check any HTTPS site's TLS certificate. The tool establishes a real SSL handshake, parses the X.509 certificate, and reports issuer, validity dates, days remaining, common name, subject alternative names, and serial — server-side, no JS required.
The SSL Certificate Checker establishes a real TLS connection to any domain on port 443, captures the certificate the server presents, parses it with OpenSSL, and displays the data that matters for security operations: validity status, issuer, common name, valid-from and valid-until dates, days remaining before expiry, subject alternative names (SANs), and the certificate's serial number. The check is server-side — your browser never has to make a CORS-restricted cross-origin TLS handshake — and the result is rendered as plain HTML so search engines can index per-domain certificate snapshots.
What is different about this tool: real X.509 parsing, not a metadata cache. Many free SSL checkers display data scraped from Certificate Transparency logs, which can be hours or days stale. This tool opens a fresh TLS handshake to the target domain every time it has nothing cached, and caches results for one hour. The output reflects what the server is actually serving right now — useful for verifying renewals, debugging staging environments, and confirming that a certificate change is live before flipping DNS.
How it works under the hood
When you submit a domain, the tool extracts the registrable hostname (stripping protocol, paths, and ports) and opens a TLS connection to domain:443 via PHP's stream_socket_client() with capture_peer_cert set. The connection times out after 8 seconds — long enough for slow handshakes, short enough that broken hosts don't hang the page.
Certificate parsing. Once the handshake completes, the tool extracts the peer certificate from the stream context and runs openssl_x509_parse() against it. The parsed structure exposes the subject (Common Name), issuer (Organisation), validity timestamps, serial number, and the X.509v3 Subject Alternative Name extension. All values are rendered to the page as plain HTML — searchable, indexable, scrapable.
Verification disabled by design. The TLS connection is established with verify_peer and verify_peer_name set to false. This is deliberate: we want to inspect the certificate even if it's expired, self-signed, or has a hostname mismatch. Verification disabled means the tool can report on broken certificates, which is half the point — secure connections work; the value is in surfacing the broken ones.
Days-remaining warning. When the certificate expires within 30 days, the Days Remaining field is rendered in amber. When it has already expired, the Status field flips to red and Days Remaining shows 0. These visual cues are deliberate — most certificate-related outages are caused by missed renewal reminders, and 30-day warning is the industry-standard pre-expiry escalation window.
Caching and rate. Results are cached for one hour (per WordPress transient API) keyed by domain. Repeat lookups within the cache window return the same rendered HTML — your browser doesn't trigger a fresh TLS handshake against the target for every page load. This protects target servers from being hammered when a single tool URL goes viral.
What this tool does NOT do. It does not validate the full certificate chain back to a trusted root (use SSL Labs for that). It does not check OCSP revocation status. It does not test cipher suite negotiation, TLS version support, or HSTS headers. For a comprehensive TLS audit, use SSL Labs alongside this tool — ours gives you the certificate facts in 2 seconds; theirs gives you the full A-to-F report in 90 seconds.
Five real-world use cases
Verify a renewal landed on the production server
You renewed your TLS certificate yesterday and want to confirm the new one is actually being served. Paste the domain into the checker — the Valid From date should match yesterday (give or take the certificate authority's signing window). If you still see the old Valid From date, the renewal didn't deploy correctly: check whether your web server reloaded after the renewal, whether your CDN is still serving a cached copy of the old certificate, or whether the new certificate landed in the wrong directory.
yourdomain.com
Audit certificate inventory for an organisation
You've inherited a portfolio of 30 production domains and you don't know which are about to expire. Run this tool against each domain in turn (or write a one-line shell loop that calls our results URL with each domain as the ?q= parameter). Record the Valid Until date for each and sort by ascending expiry. Anything within 30 days goes to the top of the action queue. This is a 20-minute task that prevents the kind of certificate-expiry outage that takes down production for hours.
Verify a staging environment certificate before cutover
You're about to flip DNS from staging to production and you want to confirm the new environment's certificate is correctly issued for the right hostname. Run the checker against the staging hostname — verify Common Name and Subject Alternative Names match what production needs to serve. A wrong CN or missing SAN now costs you 5 minutes; the same mistake discovered after the DNS flip costs you a 30-minute outage and an angry status-page incident.
Detect typosquatting domains using suspicious certificates
You found a domain that looks like a typosquat of your brand. Run it through the checker — many phishing operators get free Let's Encrypt certificates to make their lookalike domains look legitimate. The Issuer field will tell you whether the cert was issued by Let's Encrypt (highly common for phishing) versus an EV cert from DigiCert / Sectigo (less common). Combined with the WHOIS Lookup tool to identify the registrar and registration date, this gives you the evidence pack for a takedown request.
Bug bounty: find expired certs as low-hanging reports
Bug-bounty programmes vary on whether expired certificates are in scope, but many treat them as low-severity findings — particularly for any subdomain in scope. Run the checker against discovered subdomains during your recon phase. Expired certificates on production-adjacent hostnames (api-old.target.com, staging.target.com) often indicate forgotten infrastructure that's also forgotten in patching — so the expired cert is sometimes a lead to a juicier finding behind it.
api-old.target.com
Common mistakes & edge cases
Treating a Valid status as proof of secure configuration
This tool reports certificate validity, not TLS configuration security. A site can serve a perfectly valid Let's Encrypt cert while supporting TLS 1.0, weak ciphers, and lacking HSTS. For a full TLS posture audit including cipher negotiation and protocol versions, use Qualys SSL Labs (ssllabs.com/ssltest/). This tool answers "is the certificate valid?"; SSL Labs answers "is the TLS configuration secure?".
Confusing certificate expiry with domain expiry
An SSL certificate expiring is not the same as the domain registration expiring. A certificate is the cryptographic proof of identity for the duration the CA signed it for; the domain is the registered name itself. A site can have a fresh new certificate and still lose its domain registration next month if the registrar bill goes unpaid. Use this tool for cert expiry; use the Domain Age Checker (and your registrar's renewal dashboard) for domain expiry.
Assuming the certificate chain is complete because the leaf is valid
This tool reports the leaf certificate that the server presents. The full chain (leaf, intermediate, root) might be incomplete — a server could be missing the intermediate certificate, which causes browser warnings even though the leaf itself is valid. To verify chain completeness, use SSL Labs. A common deployment mistake is uploading only the leaf certificate to a new server and forgetting to install the intermediate; this tool will report the leaf as valid while real users see browser warnings.
Reading Subject Alternative Names as exhaustive
The SAN list shows hostnames the certificate is valid for. It does NOT show every hostname the server is configured to serve. A server might host 100 domains via SNI but the certificate this tool returned was just for the one you queried. To enumerate all hosts on an IP, use IP-based discovery (RIPEstat, Censys), not the SAN list.
Trusting the Issuer field without context
Issuer just tells you which CA signed the certificate. "Let's Encrypt Authority X3" is the signing authority for an enormous fraction of legitimate websites — but also for an enormous fraction of phishing and typosquatting domains, because Let's Encrypt is free and automated. EV (Extended Validation) certificates from CAs like DigiCert require business verification and are harder for phishers to obtain — but EV is being deprecated by browsers and EV-only assumptions are increasingly fragile. Use Issuer as one signal among many, never as the deciding factor.
Using this on staging environments behind VPN
The tool runs server-side from our infrastructure. If your staging environment is behind a VPN, IP allowlist, or corporate firewall, our server can't reach it — you'll get a connection error. For private hostnames, use OpenSSL directly from a machine inside your network: openssl s_client -connect staging.internal:443 -showcerts
Frequently Asked Questions
Paste the domain into the checker above. The tool establishes a real TLS connection to the domain on port 443, parses the certificate the server presents, and reports validity status (Valid or Expired), expiry date, issuer, common name, days remaining, and subject alternative names. The check takes around 2 seconds. No account, no rate limit beyond the one-hour result cache, no fields to fill in beyond the domain itself.
An expired certificate means the cryptographic signature attesting to the domain's identity has passed its validity window. Browsers display a full-page security warning ("Your connection is not private") and most refuse to load the site without a manual override. The site is still technically reachable, but virtually no users will proceed past the warning. Renewal must be installed and the web server reloaded before normal operation resumes.
Public TLS certificates issued by browser-trusted CAs are now capped at 398 days (about 13 months) — down from 825 days in earlier years. Apple drove the policy change to limit the impact-window of compromised certificates. Some CAs offer multi-year purchase agreements with annual reissuance. Let's Encrypt issues 90-day certificates and is moving to a 6-day option for automated environments.
SSL (Secure Sockets Layer) is the older protocol family, deprecated by 2015. TLS (Transport Layer Security) is its successor and what every modern HTTPS connection actually uses. The terms are still used interchangeably in marketing copy — "SSL certificate" is colloquial for what is technically a TLS certificate. The X.509 certificate format itself is the same regardless of which protocol negotiates the connection.
Several common causes: (1) the certificate chain is incomplete — your server is missing the intermediate certificate; (2) the hostname you're testing differs from what's in the certificate's Common Name or Subject Alternative Names; (3) your local browser caches the old cert and you need a hard reload; (4) browser-specific policy rejects the certificate (e.g. HPKP pinning, CT log requirements, CA distrust events). Use Qualys SSL Labs for a chain-completeness audit when this tool reports valid but browsers don't agree.
Yes. Let's Encrypt is a free, automated, browser-trusted CA operated by the Internet Security Research Group (ISRG). Its root certificate is in every major browser and operating system trust store. Browsers do not distinguish between a Let's Encrypt certificate and a paid commercial certificate for cryptographic security purposes — both provide the same TLS encryption. Let's Encrypt certificates are domain-validated only (DV); they don't perform organisation verification (OV) or extended validation (EV).
Use Qualys SSL Labs at ssllabs.com/ssltest/ — it walks the full chain, identifies missing intermediates, and grades the overall TLS configuration A through F. Our tool reports the leaf certificate (the one for the specific domain) which is what most operations questions need. Combine the two for full coverage: ours for fast cert facts, SSL Labs for full TLS audit.
Yes — that's what this tool does. The TLS handshake required to retrieve the certificate is performed by our server, not your browser. You don't visit the target site, your IP isn't logged by the target, and no cookies are exchanged. This is useful for vetting suspicious domains where you'd rather not load arbitrary content.
The SAN extension in an X.509 certificate lists all hostnames the certificate is valid for. Modern certificates often cover multiple domains (the apex `example.com`, the `www.example.com` subdomain, and sometimes wildcards like `*.example.com`). The browser checks SAN entries — if the hostname you're visiting isn't listed, the browser treats the certificate as not matching even if it's otherwise valid.
For commercial CAs (DigiCert, Sectigo, GlobalSign), log into your CA dashboard 30+ days before expiry, generate a CSR on your server, submit it to the CA, install the issued certificate, and reload your web server. For Let's Encrypt, install Certbot once and let it auto-renew via cron — Certbot renews certificates 30 days before expiry by default. Auto-renewal eliminates the entire class of "oops, we forgot" outages.