SSL certificate checker

Enter a domain. We open a TLS connection to it, the way a browser does, and show the certificate's expiry date, issuer, the names it covers and the full chain, then check that browsers and API clients will trust it: hostname match, missing intermediate certificate, self-signed or expired certificates, old TLS 1.0/1.1 still switched on and whether TLS 1.3 is offered. Free, no signup.

30 free checks a day. Ports 443 and 8443 (add :8443 to the domain).

Certificate lifetimes on 18 big sites

We ran this checker on 18 well-known sites on 25 October 2026. Every certificate was valid and every chain complete. 11 of them now use certificates of 90 days or less, and the longest one left (python.org, 397 days) was issued before March 2026, when the maximum dropped to 200 days. Two still accept TLS 1.1.

Site	Lifetime, issuer, days left
python.org	397 days · GlobalSign 111 days left; issued before the 200-day cap
stripe.com	199 days · DigiCert 196 days left
nytimes.com	199 days · DigiCert (Thawte) 145 days left
amazon.com	198 days · DigiCert (GeoTrust) 162 days left
reddit.com	180 days · DigiCert 114 days left
bbc.co.uk	156 days · GlobalSign 90 days left
microsoft.com	100 days · Microsoft (DigiCert root) 96 days left
github.com	90 days · Sectigo 35 days left
wikipedia.org	90 days · Let's Encrypt 68 days left
mozilla.org	90 days · Google Trust Services 48 days left
cloudflare.com	90 days · Google Trust Services 40 days left; still accepts TLS 1.1
shopify.com	90 days · Google Trust Services 72 days left
php.net	90 days · Let's Encrypt 83 days left
wordpress.org	90 days · Let's Encrypt 57 days left
stackoverflow.com	90 days · Let's Encrypt 77 days left
nginx.org	90 days · Let's Encrypt 79 days left; no TLS 1.3
apple.com	84 days · Apple (DigiCert root) 58 days left
google.com	84 days · Google Trust Services 56 days left; still accepts TLS 1.1

Why expiry dates matter more every year

Under CA/Browser Forum ballot SC-081, public TLS certificates may be valid for at most 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. A certificate you renew by hand once a year is no longer possible; renewal has to be automatic (ACME clients such as certbot, or a host or CDN that does it for you). The common failure is a renewal job that broke silently months ago, so check the days left here, or monitor it from code (below).

What the errors mean

Incomplete chain	The server sends its own certificate but not the intermediate one that links it to a trusted root. Desktop Chrome often fetches the missing piece itself, so the site looks fine to you, while Firefox, Android apps, curl, Python requests and webhooks fail. On nginx, point `ssl_certificate` at `fullchain.pem`, not `cert.pem`.
Hostname mismatch	The certificate doesn't list the name you typed. Typical causes: a certificate for `example.com` only, served on `www.example.com`, or a new subdomain pointing at a server with someone else's certificate.
Self-signed or untrusted root	Fine for internal tools whose clients you control; on a public site every visitor gets a warning page.
TLS 1.0 / 1.1 accepted	Browsers removed them in 2020 and PCI DSS has banned them since 2018. Leaving them on rarely breaks anything, but security scanners flag it. nginx: `ssl_protocols TLSv1.2 TLSv1.3;`

Check expiry from code

A short Node script that warns when a certificate has under 21 days left, for a cron job or CI:

// check-cert.mjs: node check-cert.mjs example.com
import tls from "node:tls";
const host = process.argv[2];
const s = tls.connect({ host, port: 443, servername: host }, () => {
  const days = Math.floor((new Date(s.getPeerCertificate().valid_to) - Date.now()) / 864e5);
  console.log(host, days, "days left");
  s.end();
  process.exitCode = days < 21 ? 1 : 0;
});
s.on("error", e => { console.error(host, e.code); process.exitCode = 2; });

Get expiry alerts from the API

This check also runs over the Shotmint API, free with any key (500 checks a day, 0 credits), so a daily cron job or Make/n8n/Zapier scenario can warn you weeks before a certificate expires, without opening TLS sockets yourself:

curl -s "https://shotmint.creasework.com/v1/check?type=ssl&url=example.com" \
  -H "X-API-Key: YOUR_KEY"
# {"type":"ssl", "credits_used":0, "host":"example.com", "ok":true, "trusted":true,
#  "hostname_match":true, "days_left":60, "valid_to":"2026-12-25T22:56:35.000Z", "issuer":..., ...}

# cron: print a warning when fewer than 21 days are left
curl -s "https://shotmint.creasework.com/v1/check?type=ssl&url=example.com" -H "X-API-Key: YOUR_KEY" \
  | jq -e '.days_left > 21' > /dev/null || echo "Renew the example.com certificate"

SSL expiry badge for your README

Put the days left on your certificate where your team already looks: a free, keyless badge for a GitHub README, status page or wiki. It is green from 30 days left, yellow under 30, red under 14 or when the certificate is expired or invalid, and is re-checked every 6 hours. Clicking it opens this checker for the full report.

[![SSL certificate](https://shotmint.creasework.com/badge/ssl/example.com.svg)](https://shotmint.creasework.com/ssl-checker?host=example.com)

Replace example.com with your domain (after a check above, this snippet already uses it). HTML: <img src="https://shotmint.creasework.com/badge/ssl/your-site.com.svg" alt="SSL certificate">. Uptime badge: is it down?

A valid certificate doesn't mean the page works. The Shotmint API loads it in Chromium and returns a screenshot or PDF, with the page's own HTTP status in an X-Page-Status header, so a monitoring job can see what visitors see. 25 free renders a month.

More free checks for the same site: HTTP header checker (HSTS and other security headers), redirect checker (http → https), robots.txt checker.