SSL Certificate Checker
Instantly inspect any domain's SSL certificate — validity, expiry, issuer, SANs, chain, and TLS protocol.
What the SSL Certificate Checker analyses
Need a certificate? Generate a free SSL certificate → · Run a full security scan →
Certificate validity & expiry
The checker opens a real TLS connection to your server on port 443 (or any custom port you specify) and reads the certificate directly — the same way a browser would. It reports the exact valid-from and valid-until dates, the number of days remaining until expiry, and flags the certificate as valid, expiring soon (under 30 days), or already expired. This gives you an accurate picture of exactly what certificate your server is currently serving, including any that may differ from what you last deployed.
Certificate chain verification
A complete TLS certificate chain consists of three layers: your leaf (end-entity) certificate, one or more intermediate certificates from the CA, and a trusted root certificate. When a server omits the intermediate certificates, most desktop browsers still work because they have the intermediates cached — but Android, curl, and many API clients do not cache intermediates and will fail with an "untrusted certificate" error. The checker visualises your complete chain so you can immediately see whether intermediates are present and where the chain terminates.
Subject Alternative Names (SANs)
Modern TLS certificates no longer rely on the Common Name field to specify which hostnames they secure — they use the Subject Alternative Names (SAN) X.509 extension. All browsers have ignored the CN field for hostname matching since 2017. The checker lists every SAN in the certificate, including wildcard entries like *.example.com. This is the fastest way to verify that a certificate actually covers the hostname you are trying to secure before and after deployment.
TLS protocol & cipher suite
The checker reports the TLS protocol version (TLS 1.2 or TLS 1.3) and the cipher suite that was negotiated during the handshake with your server. TLS 1.3 is the current standard — it removes weak cipher suites and reduces handshake round-trips for faster connections. TLS 1.0 and TLS 1.1 are deprecated by all major browsers and violate PCI-DSS compliance requirements. If your server still negotiates TLS 1.0, this is a security vulnerability that should be corrected in your server configuration immediately.
Issuer, serial number & fingerprint
The checker shows the full issuer distinguished name (which CA issued the certificate), the serial number assigned by the CA, and the SHA-256 fingerprint — a cryptographic hash uniquely identifying this specific certificate. The fingerprint is useful for certificate pinning, for verifying that a certificate hasn't been replaced unexpectedly, and for incident response when you need to confirm which exact certificate was active at a given time. You can cross-reference the serial number against the CA's Certificate Transparency logs at crt.sh.
Expiry reminders by email
After checking any domain, click "Set Reminder" next to the Days Remaining field to schedule a free email notification before the certificate expires. You can choose to be reminded 7, 14, 30, or 60 days in advance. This is particularly valuable for manually managed certificates, staging environments, or internal services where automated renewal tools like Certbot are not set up. A single advance warning can prevent the downtime and emergency scramble of dealing with an expired certificate in production.
Frequently asked questions
How do I check if my SSL certificate is valid?
Enter your domain name in the input field above and click "Check SSL". The checker opens a real TLS connection to your server, reads the certificate directly, and in seconds shows you the validity status, exact expiry date, days remaining, issuer, TLS protocol, cipher suite, SHA-256 fingerprint, all SANs, and the full certificate chain. No browser extension or software installation required.
What does the SSL certificate checker show?
The checker displays: Common Name (the primary domain the cert was issued for), full issued-to Subject and Issuer distinguished names, Valid From and Valid Until dates, Days Remaining (colour-coded green/amber/red), TLS protocol version, negotiated cipher suite, serial number, SHA-256 fingerprint, all Subject Alternative Names (SANs) including wildcards, and the complete certificate chain from leaf through intermediates to root — each card showing the CN, issuer, and validity dates of that chain link.
Can I check SSL on a custom port?
Yes. Append a colon and the port number to your domain — for example example.com:8443. This works for non-standard HTTPS ports, LDAP over TLS (636), IMAPS (993), SMTPS (465), MySQL over TLS (3306), or any other TCP service that presents a TLS certificate. The checker performs a standard TLS handshake on whichever port you specify.
How do I get notified before my SSL expires?
After checking your domain, click the "Set Reminder" button that appears next to the Days Remaining field. Enter your email address and choose how far in advance you want the notification: 7, 14, 30, or 60 days before expiry. You will receive a single reminder email at the configured time. This is especially useful for manually renewed certificates on staging environments, internal tools, or mail servers where automatic renewal is not configured.
Why does my certificate show as invalid even though it was recently issued?
The most common cause is a missing intermediate certificate. Your web server must send the complete chain — the leaf certificate for your domain plus all intermediate certificates from the CA — not just the leaf alone. Desktop browsers often work despite missing intermediates because they cache them from prior visits, but mobile browsers, curl, Python's requests library, and most API clients do not cache and will fail. Fix this by configuring your server to use fullchain.pem instead of cert.pem.
What is the difference between cert.pem and fullchain.pem?
cert.pem contains only the end-entity certificate for your domain. fullchain.pem contains that certificate concatenated with all intermediate certificates, forming the complete chain browsers need to verify trust back to a root CA. For Nginx and Apache you should always use fullchain.pem — using just cert.pem will cause intermittent failures on clients that don't have the intermediates cached.