TLS Certificate Checker

Check a site's TLS/SSL certificate: subject/issuer, validity dates, SANs, chain completeness, and common HTTPS misconfigurations. Optionally follow redirects to verify the final destination is HTTPS with a valid certificate. Export JSON/PDF reports.

Loading…

About TLS Certificate Checker

When HTTPS breaks, users see scary warnings and bots stop trusting your site. This tool fetches a URL, optionally follows redirects, and inspects the TLS certificate that protects the final HTTPS endpoint. It helps you catch expiring certificates, incomplete chains, hostname/SAN mismatches, and other issues that commonly cause browser errors and SEO/availability problems.

Features

  • Inspect certificate subject and issuer (who it's for, who issued it).
  • Validate dates: notBefore / notAfter, and warn on imminent expiration.
  • Check SANs (Subject Alternative Names) and hostname coverage (www vs apex, subdomains).
  • Detect certificate chain issues (missing intermediates / incomplete chain).
  • Optional redirect following to validate the final URL's HTTPS enforcement.
  • Identify common HTTPS pitfalls (wrong host, wrong certificate, mixed redirect flows).
  • Copy-friendly results and findings for incident tickets.
  • Download JSON and PDF reports for documentation and regression checks.

🧭 How to use for tls-certificate-checker

1

Paste the URL to test

Enter the target URL. You can paste https://example.com or even http://example.com if you want to confirm it ultimately upgrades to HTTPS.

2

Enable "Follow Redirects" for real-world behavior

If you want to validate the actual destination users and crawlers reach (http→https, non-www→www), keep Follow Redirects enabled.

3

Run the check and review the summary

Check the key items: validity dates, hostname/SAN match, and whether the chain is complete.

4

Inspect findings and fix the root cause

If you see warnings (expiring soon, mismatch, incomplete chain), fix them at the TLS termination layer (CDN, reverse proxy, load balancer, or web server).

5

Export JSON/PDF for tracking

Download a report to attach to ops/SEO tickets or to keep a before/after snapshot.

Technical specs

Input and operation

This tool checks a URL and inspects the TLS certificate for the resolved HTTPS endpoint.

CapabilityDetails
Supported URL formsHTTP or HTTPS URLs (redirect following can be enabled).
Redirect handlingOptional; when enabled, follows up to the configured max redirects.
TLS focusInspects certificate properties and common misconfigurations.

Defaults and limits

Fetch and safety defaults are tuned for predictable behavior.

SettingValue
Follow RedirectsEnabled
Max Redirects10
Timeout15000 ms
User-AgentEncode64Bot/1.0 (+https://encode64.com)
Private networksNot allowed

What gets checked

Checks are designed around the most frequent breakages seen in production: expiration, hostname mismatch (SAN coverage), and chain completeness. Redirect following helps catch cases where HTTPS is only valid on the final canonical host.

A valid certificate is necessary but not sufficient for strong security. Pair this with HSTS and security header audits for hardened deployments.

Command line

Use OpenSSL and curl to confirm certificate details from your own terminal and compare with what the tool reports.

macOS / Linux

Show certificate chain (SNI) for a host

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

Useful to inspect the presented leaf cert and intermediate chain.

Extract expiry date quickly

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Prints notBefore / notAfter.

List SANs

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Shows which hostnames the cert covers.

Verify HTTP redirects to HTTPS

curl -I http://example.com

Check Location header and final scheme.

Follow redirects and show final URL

curl -IL http://example.com | sed -n '1,120p'

Helps detect redirect chains and non-canonical endpoints.

Always use -servername with openssl s_client on virtual-hosted servers/CDNs. Without SNI, you can get the wrong certificate.

Use cases

Prevent certificate expiration outages

Identify certificates nearing expiry so you can renew before users and bots hit browser errors.

  • Weekly certificate health checks
  • Audit domains after DNS or CDN changes

Fix incomplete certificate chain issues

Detect missing intermediates (common on custom server setups) that break older clients and some crawlers.

  • Misconfigured Nginx/Apache chain bundle
  • Load balancer missing intermediate certs

Debug hostname/SAN mismatch (www vs apex)

Confirm the certificate covers the exact host users reach, including www/non-www and subdomains.

  • Apex works but www breaks
  • API subdomain missing from SAN list

Verify HTTPS enforcement via redirects

Ensure http URLs redirect to the canonical https endpoint with a valid certificate.

  • http→https with 301
  • non-www→www canonicalization

❓ Frequently Asked Questions

❓Why can a browser say "certificate not trusted" even if HTTPS is enabled?

Common causes are an expired certificate, an incomplete chain (missing intermediate), a hostname mismatch (SAN doesn't include the host), or serving the wrong certificate due to SNI/virtual hosting misconfiguration.

❓What are SANs and why do they matter?

SANs (Subject Alternative Names) are the hostnames a certificate is valid for. If your site is accessed via both example.com and www.example.com, the certificate should cover both (or you should redirect consistently to a covered host).

❓Is it OK if http redirects to https?

Yes—that's recommended. Just make sure the final HTTPS destination presents a valid certificate and the redirect chain is short and consistent (prefer 301 for canonical redirects).

❓Does this tool check TLS versions/ciphers?

This tool is focused on certificate inspection and common misconfigurations. For protocol/cipher hardening (TLS 1.2/1.3, weak ciphers), use a dedicated TLS configuration scanner.

❓What's the difference between leaf, intermediate, and root certificates?

The leaf cert is your site's certificate. Intermediates link it to a trusted root CA. Browsers trust roots, so missing intermediates can prevent building a valid trust chain.

Pro Tips

Best Practice

Renew certificates early and automate renewals (ACME) wherever possible.

Best Practice

Ensure SANs cover every public hostname you serve (www, apex, API subdomains) or enforce a single canonical host via redirects.

Best Practice

Always serve the full chain (leaf + intermediates). Many outages come from incomplete chain bundles after migrations.

Best Practice

If you enable redirects, keep them minimal: one hop to the canonical https URL is ideal.

Security Tip

Pair valid TLS with HSTS and security headers for stronger real-world protection.

Additional Resources

OpenSSL s_client documentation
Documentation
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Documentation
Let's Encrypt: Certificate basics
Documentation

Other Tools