What does a TLS certificate prove?
A TLS certificate is an X.509 document (RFC 5280) that binds a public key to the names listed in its subjectAltName for a limited period, signed by the issuing certificate authority. A browser accepts it only when the dates are current, the name it requested appears in the SAN (RFC 9525) and the signatures lead to a root it already holds; the certificate alone proves nothing until that chain and those names are checked.
Security note: A certificate is public, but the private key that matches it must never leave the server: never paste a private key into a web page, and replace any certificate whose key may have been exposed.
How to use SSL Certificate Checker
- Enter the host name (www.example.com), an IP address or a whole URL. Change the port when the service is not on 443, or write host:port.
- For an IP address, put the site's host name in Server name (SNI) so the server returns that site's certificate rather than its default one.
- Press Check certificate. If the site is served through Cloudflare the page tells you at once; then paste the certificate instead (export it from the browser's padlock menu as PEM).
- Read the Summary and the Findings first, then the Certificate fields. For the issuing certificates, open the Certificate Chain Checker.
SSL Certificate Checker features
- Reads the certificate a server really presents: the Mutqan server opens a TLS handshake to the host and port you give and decodes the Certificate message itself, for TLS 1.3 as well as TLS 1.2
- Decodes a pasted PEM certificate entirely in your browser, with nothing sent, for sites the server cannot reach and for certificates that are not deployed yet
- Days left, validity window, issuer, Subject Alternative Names, public key, signature algorithm, serial number and SHA-256 and SHA-1 fingerprints in one view
- Checks the host name against the SAN entries the way browsers do (RFC 9525): one-label wildcards only, the Common Name only when no SAN exists
- A Server name (SNI) field to ask an IP address for a specific site's certificate, so an origin server behind a CDN can be checked directly
- Plain findings for what needs action: expired or not yet valid, renewal due within 30 or 7 days, a name the certificate does not cover, SHA-1, short RSA keys, a missing serverAuth purpose
- The connection details of the handshake (address, protocol, cipher suite, ALPN, timings) and the certificate as PEM, ready to copy or download
Inputs and outputs
Inputs
- Host name or URL: a name, an IPv4 or IPv6 address, host:port, [IPv6]:port or a full URL (its host and explicit port are used, the path is ignored).
- Port: 443 unless the service runs elsewhere (8443, 993 for IMAPS, 465 for SMTPS…); port 25 is never connected.
- Server name (SNI), optional: the site name to request when the host is an address, or to test one virtual host of a shared server.
- Or a pasted PEM certificate (at most 256 KB of text): when present, nothing is fetched; the first CERTIFICATE block that decodes is read, and the host field, if filled, is only matched against it.
Outputs
- Summary: days left, the expiry date, whether the certificate names the host (and how), the issuer and the key.
- Findings: the problems worth acting on, in plain sentences, or a line saying none of these checks found one.
- Certificate: subject, SAN list, issuer, validity in UTC, key, signature algorithm, serial, fingerprints, key usages, OCSP, CA issuers and CRL addresses, embedded SCT count.
- Connection (live check only): the address connected to, port, SNI sent, negotiated protocol and cipher suite, ALPN, handshake and DNS times, number of certificates sent; and the certificate as PEM.
SSL Certificate Checker example
The example certificate for www.example.com, pasted (checked on 14 October 2026)
Input:
Host name: www.example.com
Pasted certificate: -----BEGIN CERTIFICATE----- MIICmzCCAkGgAwIBAgIUOw09… -----END CERTIFICATE----- (the page's example, issued by "Example Issuing CA R1")Output:
Days left 7291 · Valid until 2046-10-01 · Names this host ✓ (listed in the SAN) · Issued by Example Issuing CA R1 · Public key EC P-256 (256 bits)
Findings: None of the checks above found a problem. Whether a browser trusts the issuer, and whether the certificate was revoked, is not checked here.
Subject Alternative Names: www.example.com, example.com · Signature algorithm ecdsa-with-SHA256 · Extended key usage serverAuth
Note: The certificate was decoded in your browser; nothing was sent.How to read the SSL Certificate Checker results
Days left counts whole days to notAfter in UTC. Fewer than 30 is a warning to confirm that renewal is scheduled; fewer than 7 means renew now; a negative number means browsers already refuse the certificate.
Names this host ✓ "listed in the SAN" is the only result browsers accept. "Common Name only" means the certificate has no SAN: current browsers reject it even though the name looks right. ✗ means the exact name you checked is not covered — a wildcard does not cover the bare domain or two labels deep.
"Issuer name equals subject" ✓ means the certificate is self-issued (a name comparison, not a signature check). That is expected for a root CA and wrong for a public website.
A clean Findings list means the dates, the name, the key size, the signature hash and the purpose are in order. It does not mean the certificate is trusted or unrevoked: this page has no root store and does not query OCSP or CRLs.
When to use SSL Certificate Checker
- Confirm that a renewed certificate is the one the server actually presents, by comparing the new expiry date and fingerprint after a deployment.
- Find out why some visitors see a name warning: www works but the bare domain does not, or a new subdomain is missing from the SAN list.
- Check the certificate of an origin server behind a CDN by entering its IP address with the site name as SNI.
- Decode a certificate file someone sent you (from a CA order or a load balancer export) before installing it, without uploading it anywhere.
- Check services on other ports — IMAPS on 993, a staging site on 8443 — that browser-based tools cannot show.
Troubleshooting
- "Served through Cloudflare": the check runs on a Cloudflare Worker, and raw connections to Cloudflare's address ranges are blocked by the platform. Paste the certificate instead, or test your origin server by IP address with the site name as SNI.
- "No TLS service answered" or "did not answer with TLS": the port is closed, filtered, or speaks plain text (port 80, or a mail port that needs STARTTLS first, such as 25 or 587). Use the implicit-TLS port (443, 465, 993, 995) or check the port with the TCP Port Checker.
- "refused the TLS handshake (alert: handshake_failure)": the server and the probe share no cipher suite or protocol version, or the server requires a client certificate. Try the TLS Configuration Checker for the versions it accepts.
- The wrong certificate comes back: the server chose its default certificate because the SNI did not match one of its sites. Check the host name spelling, or fill the Server name (SNI) field.
- "No certificate found" when pasting: copy the whole block including the BEGIN and END lines. A .cer or .der file in binary form must first be converted to PEM (Base64 text).
Frequently asked questions about SSL Certificate Checker
Why does the checker refuse my site because it is on Cloudflare?
The check runs on Cloudflare Workers and needs a raw TCP connection to read the handshake. The platform blocks raw connections to Cloudflare's own address ranges, so any site whose name resolves to Cloudflare cannot be probed from here, whatever its configuration. Paste the certificate (export it from the browser's padlock menu) to decode it, or enter your origin server's IP address with your host name in the Server name (SNI) field to check the certificate the origin itself presents.
Does a clean result mean browsers trust my certificate?
No. The checker has no trust store and does not check revocation. It reports what the certificate says, whether its dates are current, whether it names the host, and whether the server also sent the issuing certificates (the Certificate Chain Checker verifies each link's signature). Whether a browser trusts the chain depends on the roots it ships, which this page cannot see.
The certificate looks right, so why is the hostname match negative?
Only the Subject Alternative Name entries count; the Common Name is ignored when SANs exist. A wildcard such as *.example.com covers exactly one label, so it matches www.example.com but neither example.com nor a.b.example.com. Make sure the exact name visitors type, including or excluding www, is listed.
Which certificate do I see when I enter an IP address?
No server name (SNI) is sent for an address, so the server answers with its default certificate, which may belong to another site it hosts. Put the site's host name in the Server name (SNI) field to request that site's certificate from the same address.
How early should a certificate be renewed?
Renew with plenty of margin and automate it. Under CA/Browser Forum ballot SC-081v3, approved on 11 April 2025, a public TLS certificate issued from 15 March 2026 may be valid for at most 200 days, from 15 March 2027 for 100 days and from 15 March 2029 for 47 days, so manual renewals become impractical. Treat fewer than 30 days left as a warning and fewer than 7 as urgent: a renewal that fails needs time to be noticed and fixed.
Technical notes
Certificates are X.509 v3 as profiled by RFC 5280: the validity window is notBefore to notAfter, names live in the subjectAltName extension, and keyUsage, extendedKeyUsage, authorityInfoAccess (OCSP and CA issuers) and CRL distribution points say what the certificate may be used for and where its status is published. The page decodes the DER bytes with its own ASN.1 reader and shows those fields as written.
The host name is matched as RFC 9525 (which replaced RFC 6125) and browsers require: DNS names in the SAN are compared case-insensitively, a wildcard is honoured only as the whole left-most label and covers exactly one label, an IP address must appear as an IP SAN, and the Common Name is consulted only when the certificate carries no SAN at all.
In the live check the Mutqan server sends its own ClientHello over a raw TCP socket. Over TLS 1.2 the Certificate message travels in clear; over TLS 1.3 (RFC 8446) it is encrypted, so the server performs the X25519 or P-256 key exchange it offered, derives the handshake keys and decrypts it. The handshake is then abandoned: nothing but the ClientHello is ever sent.
Fingerprints are the SHA-256 and SHA-1 digests of the DER encoding, in the colon-separated form browsers display, so you can compare them with what a browser or a monitoring system shows.
Limitations and methodology
Vantage point: the live check connects from the Cloudflare data centre that serves your request, not from your computer. A server that answers differently by region or blocks data-centre addresses may show something else to your visitors.
Hosts whose names resolve to Cloudflare's network cannot be checked live at all — that covers a large share of websites — because the platform refuses raw sockets to those addresses.
No trust store and no revocation check: the page never says a certificate is trusted, and an OCSP or CRL revocation is not seen. Certificate Transparency logs are not queried; only the number of SCTs embedded in the certificate is shown.
The handshake is read with the probe's own offer (TLS 1.3 with AES-GCM, or TLS 1.2 and below), so a server that only accepts other suites may refuse it even though browsers connect.
Security and privacy
A pasted certificate is decoded in your browser and never leaves it. In the live check the host, port and server name you enter go to the Mutqan server, which resolves the name and opens one connection to it; nothing about the target or the result is stored. Certificates are public data, but never paste a private key — the page refuses text that contains one.
References
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThe profile of the certificates TLS uses: the validity window, the subjectAltName, key usage and basic constraints extensions, and the path validation algorithm that links a certificate to its issuer.
- RFC 9525: Service Identity in TLSHow a client checks that a certificate names the server it meant to reach: DNS names in the subjectAltName, one-label wildcards only, and no fallback to the Common Name. Replaces RFC 6125.
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3The TLS 1.3 handshake and record protocol that protect HTTPS traffic.