UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

SSL Certificate Checker

Peek TLS certificate metadata with SSRF-safe hostname rules

About SSL Certificate Checker

SSL Certificate Checker on UtilityKit inspects the TLS certificate on any public-facing hostname and returns the issuer chain, validity window, Subject Alternative Names, fingerprints, and protocol metadata — in seconds, from any browser, without openssl or any local tooling. A valid, unexpired TLS certificate is a prerequisite for HTTPS, browser trust indicators, HSTS preloading, and search engine ranking. When a certificate expires silently or is misconfigured, users see browser warnings that shatter trust and prevent access.

Why use SSL Certificate Checker

Expiry Monitoring

See the exact Not After date and calculate days remaining before expiry without any local tooling. Catch certificates approaching the 30-day renewal threshold before users see browser warnings.

SAN Coverage Verification

Subject Alternative Names list every hostname covered by the certificate. Verify that all your subdomains and domains are included before deploying a new certificate to production.

Issuer Chain Visibility

See the certificate authority, intermediate CA, and root CA in the chain. A missing intermediate certificate is one of the most common causes of trust errors on mobile devices that do not cache intermediates.

Non-Standard Port Support

Check TLS certificates on any port — SMTPS (465), IMAPS (993), LDAPS (636), custom HTTPS ports, and internal services — not just port 443. Useful for mail server and microservice certificate audits.

Debug Expired and Self-Signed Certs

Relaxed TLS verification means expired, self-signed, and chain-broken certificates still return full metadata for diagnosis instead of triggering a connection failure that hides all certificate details.

Fingerprint Verification

SHA-256 fingerprints allow you to confirm the same certificate is being served across multiple servers in a load-balanced cluster or to verify a certificate has been replaced after renewal.

How to use SSL Certificate Checker

  1. Enter the hostname without https:// or any path — for example, utilitykit.tools or api.example.com. The tool connects directly to the hostname at the TLS layer.
  2. Leave the port at 443 for standard HTTPS. Change the port to check non-standard HTTPS services, SMTPS on port 465, LDAPS on port 636, or any other TLS-wrapped service.
  3. Click Inspect. The UtilityKit backend opens a TLS connection to the hostname:port, retrieves the certificate presented by the server, and returns the metadata as structured JSON.
  4. Review the validity window — check Not Before and Not After dates to determine when the certificate was issued and how many days remain until expiry.
  5. Check the Subject Alternative Names array to confirm the certificate covers all the hostnames your site serves — missing a subdomain from the SAN list causes browser warnings on that subdomain.
  6. Note the issuer chain and verify the certificate authority matches your expected CA — unexpected CAs may indicate a CDN interception, certificate misissuance, or an incorrect certificate installed on the server.

When to use SSL Certificate Checker

  • When a certificate renewal is due and you want to verify that the new certificate has been deployed correctly across all servers in the cluster before removing the old one.
  • When users report browser security warnings and you need to diagnose whether the cause is an expired certificate, a missing intermediate, a hostname mismatch in the SAN list, or a self-signed certificate.
  • When auditing a newly launched service to confirm the certificate authority is a trusted public CA, the certificate covers the correct hostnames, and TLS 1.3 is the active protocol.
  • When debugging email delivery issues and you need to check whether the mail server's TLS certificate on port 465 or 587 is valid and covers the MX hostname expected by sending servers.
  • When preparing a domain for HSTS prelist submission — the presubmission requirement is a valid certificate with no expiry warnings, and this tool surfaces all relevant fields in one check.
  • When rotating certificates after a CA compromise or misissuance event and you need to confirm the old certificate is no longer being served by any of the origin servers in the rotation.

Examples

Valid production certificate inspection

Input: Hostname: utilitykit.tools | Port: 443

Output: { "subject": { "CN": "utilitykit.tools" }, "issuer": { "O": "Let's Encrypt", "CN": "E6" }, "validFrom": "2026-03-15T00:00:00.000Z", "validTo": "2026-06-13T23:59:59.000Z", "daysRemaining": 37, "subjectAltNames": ["utilitykit.tools", "www.utilitykit.tools"], "protocol": "TLSv1.3", "fingerprint256": "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99", "serialNumber": "0x03A1B2C3D4E5F6A7" }

Expired certificate with chain details

Input: Hostname: expired.badssl.com | Port: 443

Output: { "subject": { "CN": "*.badssl.com" }, "issuer": { "O": "DigiCert Inc", "CN": "DigiCert SHA2 Secure Server CA" }, "validFrom": "2015-04-09T00:00:00.000Z", "validTo": "2015-04-12T12:00:00.000Z", "daysRemaining": -3982, "subjectAltNames": ["*.badssl.com", "badssl.com"], "protocol": "TLSv1.2", "expired": true }

Wildcard certificate covering multiple subdomains

Input: Hostname: mail.example.com | Port: 465

Output: { "subject": { "CN": "*.example.com" }, "issuer": { "O": "Sectigo Limited", "CN": "Sectigo RSA Domain Validation Secure Server CA" }, "validFrom": "2026-01-01T00:00:00.000Z", "validTo": "2027-01-01T23:59:59.000Z", "daysRemaining": 239, "subjectAltNames": ["*.example.com", "example.com"], "protocol": "TLSv1.3", "fingerprint256": "11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00" }

Tips

  • Set up a monthly calendar reminder to check certificates with 90-day expiry (like Let's Encrypt). With 30 days remaining, automated renewal should have run — if it has not, this check surfaces that before users encounter the warning.
  • After deploying a new certificate, check the SAN list carefully on staging and production separately. CDN providers and load balancers sometimes cache an older certificate for minutes to hours after a renewal, and a SAN mismatch on one origin server in a cluster can cause intermittent trust errors that are hard to reproduce.
  • If the issuer chain shows an unexpected intermediate CA — for example, a CDN provider's intermediate instead of your direct CA — this is normal when using a CDN that terminates TLS at its edge. Verify the root CA is still a trusted public root.
  • Check certificates on port 465 (SMTPS) and port 587 (submission) for mail servers. Mail certificate issues cause delivery failures and NDRs that are often misattributed to DNS problems because they surface in bounce messages rather than browser warnings.
  • Use the SHA-256 fingerprint from this tool to verify a specific certificate is deployed consistently across all servers in a load-balanced cluster. Connecting to the same hostname multiple times and comparing fingerprints reveals whether any server in the rotation still serves the old certificate after a renewal.

Frequently Asked Questions

What does the Not After date mean?▾
Not After is the expiry date of the certificate — the exact moment at which the certificate becomes invalid and browsers will refuse to trust it. After this date, any user visiting the site sees a full-page security warning that blocks access. DV certificates from Let's Encrypt expire every 90 days; commercial certificates typically expire after 1 or 2 years.
What are Subject Alternative Names?▾
Subject Alternative Names (SANs) are the list of hostnames that a single TLS certificate is valid for. A certificate might list example.com, www.example.com, and api.example.com as SANs, meaning a single certificate covers all three. Wildcard certificates like *.example.com cover all one-level subdomains as a single SAN entry. If a hostname is not in the SAN list, the browser displays a hostname mismatch error.
What causes a 'certificate chain incomplete' error?▾
A certificate chain error means the server is not serving the intermediate certificate that links the domain certificate to the root CA. Browsers that have not cached the intermediate certificate cannot verify the chain and display a trust error. Fix it by configuring your web server to serve the full certificate bundle — domain certificate plus all intermediate certificates in order.
Why does the tool show details for expired certificates?▾
The backend uses relaxed TLS verification specifically to surface certificate metadata even when the certificate is expired, self-signed, or chain-broken. This is intentional — if strict verification were used, those certificates would cause the connection to fail and no metadata would be returned, defeating the diagnostic purpose of the tool.
What TLS versions should I expect to see?▾
Modern servers should show TLSv1.3 as the negotiated protocol. TLSv1.2 is still acceptable and widely deployed. TLSv1.0 and TLSv1.1 are deprecated — they are prohibited by RFC 8996, flagged by PCI DSS, and produce browser security warnings. If you see TLS 1.0 or 1.1, disable them in your web server configuration immediately.
What is a wildcard certificate versus a multi-SAN certificate?▾
A wildcard certificate uses a *.example.com SAN that covers all immediate subdomains (www, api, mail) but not the root domain or nested subdomains (sub.api.example.com). A multi-SAN certificate explicitly lists each hostname in the SAN field and covers exactly those names, including the root domain. Wildcard certificates are simpler to manage; multi-SAN certificates provide more precise scope control.
How do I check certificates for internal services on private networks?▾
This tool only checks publicly accessible hostnames. For internal services, use openssl s_client -connect hostname:port -showcerts from a machine on the same network, or use a local TLS inspection tool. The SSRF protection in this tool deliberately blocks private IP ranges to prevent the backend from being used to probe internal infrastructure.
What is certificate transparency and does this tool check it?▾
Certificate Transparency (CT) is a public audit log of all certificates issued by trusted CAs. CT log inclusion is required by major browsers; a certificate not logged in CT is not trusted. This tool returns the cert metadata directly from the TLS handshake, not from CT logs. To verify CT compliance separately, check crt.sh or Google's CT log search for your domain.

Explore the category

DNS Lookup Tool Query public DNS records with SSRF-safe hostname validation Canonical Tag Generator Normalize URLs and generate canonical link tags for SEO-safe page metadata. Meta Tag Generator Generate essential HTML head tags for SEO and metadata in one place. XML Sitemap Generator Generate XML sitemap files from URL lists with optional metadata defaults. JavaScript String Escape Encode and decode JavaScript escape sequences for safe string handling. Twitter Card Generator Generate Twitter/X card tags and preview social metadata quickly.
Content Security Policy (CSP): What It Stops, What It Doesn't CSP is the most powerful XSS defense most sites either don't use or deploy wrong. Here's what it actually stops, what it doesn't, and how to Mar 2026 · 11 min X.509 Certificates Explained: Anatomy of the Web's Identity Layer Every HTTPS handshake, every code-signing check, every TLS-secured email rests on X.509. We dissect the fields, extensions, chain of trust, Apr 2026 · 9 min

Glossary

TLS Certificate
A digital certificate that binds a public key to a domain name and is signed by a trusted Certificate Authority. Browsers verify this certificate during the HTTPS handshake to confirm the server's identity.
Subject Alternative Name (SAN)
An extension field in a TLS certificate that lists all hostnames the certificate is valid for. Browsers check the SAN list to verify the certificate covers the hostname being accessed.
Certificate Authority (CA)
A trusted organization that issues TLS certificates after verifying domain ownership. Root CAs are pre-trusted by browsers and operating systems; intermediate CAs chain up to a root CA.
Certificate Chain
The ordered sequence of certificates from the server's domain certificate through one or more intermediate certificates to the root CA. Browsers verify the entire chain to establish trust.
SHA-256 Fingerprint
A cryptographic hash of the entire certificate that uniquely identifies it. Two certificates with different content always have different SHA-256 fingerprints, making fingerprints useful for certificate change detection.
Wildcard Certificate
A TLS certificate with a SAN entry of the form *.example.com that covers all immediate subdomains of example.com. Does not cover the root domain itself or nested subdomains like sub.api.example.com.