SSL Certificate Checker

What it does

SSL Certificate Checker establishes a TLS connection to a hostname on a given port, retrieves the server's certificate chain, and parses every relevant field: subject, issuer, serial, validity dates, Subject Alternative Names (SANs), key algorithm and size, signature algorithm, and the chain back to a trusted root. It also flags expiry warnings, hostname mismatches, weak ciphers, and missing intermediates that would cause browser trust errors. After verifying the cert, audit the security headers with HTTP Header Inspector and confirm the domain's registration with WHOIS Lookup.

When to use it

• Validating that a freshly installed certificate covers every hostname you serve, including www and non-www variants. Use DNS Lookup to confirm both hostnames resolve.
• Diagnosing a "certificate not trusted" error by checking whether the server is sending the full chain (leaf plus intermediates) and not just the leaf.
• Auditing your certificate's expiration date so you can renew before it lapses and triggers user-facing TLS errors.
• Confirming that a recent renewal actually replaced the live certificate on every load-balanced backend, not just one. Pair with DNS Checker if propagation is also in question.
• Checking whether a certificate uses a modern signature algorithm (SHA-256 or better) and key size before relying on it for production traffic.

How to read the results

The subject CN and SANs together define which hostnames the certificate is valid for — modern browsers ignore the CN entirely and trust only the SANs. The issuer is the certificate authority that signed the leaf. The chain must terminate at a CA in the browser's trust store; a missing intermediate causes "unable to verify" errors even when the leaf itself is fine. Expiry under 30 days is a warning, under 7 days is critical. If the certificate is valid but pages still flag insecure, the cause is usually mixed content or a missing HSTS — check both with HTTP Header Inspector.

Common mistakes

• Installing only the leaf certificate and assuming clients will fetch intermediates themselves — most won't, and the chain must be served by your server.
• Checking only the apex hostname when users actually connect to www, or vice versa — both must resolve to a valid certificate.
• Confusing certificate expiry with domain expiry; they are issued by different parties and on different cycles. WHOIS Lookup shows domain expiry; this tool shows cert expiry.
• Relying on the CN field rather than SANs — a certificate without the requested hostname in its SAN list will be rejected by every modern browser.

# curl — JSON response (default)
curl https://internettimes.com:80/api/v1/ssl-checker/example.com \
  -H "Authorization: Bearer YOUR_API_KEY"

# Markdown response — ingest-friendly for agents
curl "https://internettimes.com:80/api/v1/ssl-checker/example.com?format=md" \
  -H "Authorization: Bearer YOUR_API_KEY"