SSL Certificate Checker

About this tool

SSL Certificate Checker on UtilityKit connects to a public hostname over TLS from the UtilityKit server and shows the certificate it presents — no openssl needed. Enter a hostname and port (443 by default) and click Inspect. The result shows days remaining or how long ago the certificate expired, the subject and issuer names, the Valid from and Valid to dates, the serial number, and SHA-1 and SHA-256 fingerprints. Subject Alternative Names are currently listed only in the Raw JSON view, under subjectaltname. Verification is relaxed on purpose, so expired, self-signed and mismatched certificates still return their details. Only the server certificate itself is read: intermediate and root certificates, the negotiated TLS version and the cipher are not shown. Ports other than 443 work for services that use TLS from the first byte, such as 465 or 993, but not for STARTTLS ports like 587. Private, loopback and link-local addresses are blocked.

Why use it

• Expiry at a Glance: The banner shows exact days remaining or days since expiry, colour-coded so a certificate close to renewal stands out.

• Issuer Check: Subject and issuer fields show which CA signed the certificate, so an unexpected issuer or a self-signed certificate is easy to spot.

• Other TLS Ports: Check certificates on implicit-TLS ports such as 465 (SMTPS), 993 (IMAPS) or 636 (LDAPS), not just 443.

• Debug Expired and Self-Signed Certs: Relaxed verification means expired, self-signed and mismatched certificates still return their details instead of a connection error.

• Fingerprint Verification: SHA-256 and SHA-1 fingerprints let you confirm every server behind a load balancer serves the same renewed certificate.

• SAN Coverage in Raw JSON: The subjectaltname field lists every hostname the certificate covers, so you can confirm a new subdomain is included.

How to use

1. Enter the hostname without https:// or a path — for example, utilitykit.tools or api.example.com.
2. Leave Port at 443 for HTTPS, or change it for another implicit-TLS service such as SMTPS on 465 or IMAPS on 993.
3. Click Inspect. The UtilityKit backend opens a TLS connection to hostname:port and reads the certificate the server presents.
4. Check the coloured banner for days remaining (yellow under 30 days, orange under 14, red once expired) and the Valid from and Valid to rows.
5. Compare the issuer, serial number and SHA-256 fingerprint with what you expect, and open Raw JSON to read the subjectaltname list of covered hostnames.

When it helps

• 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 was issued by the expected CA and is not self-signed.
• When debugging mail delivery and you need to check the certificate on an implicit-TLS port such as 465 or 993 (STARTTLS ports like 587 are not supported).
• 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

Hostname: utilitykit.tools | Port: 443

37 days remaining  utilitykit.tools:443
Subject CN: utilitykit.tools
Subject: CN=utilitykit.tools
Issuer CN: E6
Issuer: C=US, O=Let's Encrypt, CN=E6
Valid from: Mar 15 00:00:00 2026 GMT
Valid to: Jun 13 23:59:59 2026 GMT
Serial number: 03A1B2C3D4E5F6A7B8C9
Fingerprint (SHA-256): AA:BB:CC:…:99

Hostname: expired.example.com | Port: 443

Expired 12 days ago  expired.example.com:443
Subject CN: expired.example.com
Issuer CN: R11
Valid from: Jul 05 00:00:00 2026 GMT
Valid to: Oct 03 23:59:59 2026 GMT

Raw JSON → "subjectaltname": "DNS:expired.example.com"

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 is an unexpected CA — for example a CDN provider's — this is normal when a CDN terminates TLS at its edge. Confirm the CDN's certificate still covers your hostname.
• Check mail server certificates on implicit-TLS ports such as 465 (SMTPS) and 993 (IMAPS). Port 587 uses STARTTLS, which this tool cannot negotiate, so test it with openssl s_client -starttls smtp.
• 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

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.