TLS certificate checker
Inspect the TLS certificate served at every hop in a redirect chain: subject, issuer, SANs, validity period, chain validation, TLS version, and cipher suite.
Each hop in a redirect chain can be served by a different server with a different certificate. Most tools only show the final destination, which hides expiring certs, SAN mismatches, and mixed HTTP/HTTPS hops along the way.
Why certificate checks matter beyond the padlock
Browsers show a padlock or they do not. But there is more to TLS health than that. Expiring certificates, mismatched SANs, untrusted issuers, and mixed-content redirects (an HTTP hop in an otherwise HTTPS chain) do not always trigger a browser warning, but they affect trust, security posture, and SEO.
What you see for each certificate
- Subject (CN) and issuer (CA)
- Subject Alternative Names (SANs)
- Validity period (not_before, not_after)
- Whether the certificate chain validated against trusted roots
- TLS version and cipher suite
- Per-hop visibility, not just the final destination
Common certificate problems this catches
- Certificates expiring within 30 days
- SANs that do not cover the requested hostname
- Intermediate certificates from different CAs across hops, usually a CDN misconfiguration
- Redirect chains that start on HTTPS, pass through HTTP, and return to HTTPS
- Self-signed or untrusted certificates on staging or internal redirects that leak into production
Useful for more than just your own site
TLS certificate checks are useful when evaluating vendor, partner, or third-party URLs before embedding them. They are also helpful for verifying CDN or load balancer TLS configuration after changes, and for pre-launch checks during domain or hosting migrations.
Batch check up to 500 URLs at once and filter by certificate status to focus on the issues that matter.
Frequently asked questions
What does a TLS certificate checker do?
It connects to a URL and inspects the TLS certificate served during the handshake. checkredirects.io does this at every hop in a redirect chain, not just the final destination.
Why check certificates at every hop?
Because each hop in a redirect chain can be served by a different server with a different certificate. A valid cert on the final page does not mean the intermediate hops are also valid.
Can I check certificates in bulk?
Yes. Batch check up to 500 URLs and review TLS details for each one. Filter for certificate issues and export the results.
Does this replace a dedicated SSL monitoring tool?
It is not a long-running uptime monitor. But for on-demand checks, migration QA, and batch audits, it gives you the certificate details you need without setting up a separate monitoring stack. You can also use scheduled monitors to re-check URLs on a recurring basis.
Inspect TLS certificates across your URLs
Batch up to 500 URLs, review per-hop certificate details, filter by expiring or invalid certs.