X.509 Certificate Inspector

About this tool

X.509 certificates underpin TLS/SSL, code signing, and identity verification across the internet. Reading their contents normally requires openssl commands or desktop tools. This inspector lets you paste any PEM certificate or a raw base64 DER block and instantly see a structured breakdown: Subject (CN, O, C), Issuer, validity window with a days-remaining countdown, Subject Alternative Names (SANs) listing every covered domain and IP, public key type and size, signature algorithm, serial number, and both SHA-1 and SHA-256 fingerprints. Certificates expiring within 30 days trigger a colored warning banner. Output is exportable as JSON. All parsing uses node-forge in-browser — no certificate data leaves your device.

Why use it

• No openssl binary needed — inspect certificates directly in the browser on any OS.

• Expiry countdown highlights certificates expiring within 30 days with a colored warning banner.

• Shows SANs in full, critical for checking wildcard coverage and multi-domain certificates.

• JSON export enables pasting certificate metadata into reports or scripts without reformatting.

• Completely offline-capable — certificate data never leaves your browser.

• No openssl binary needed — inspect certificates directly in any modern browser on Windows, macOS, Linux, ChromeOS, or mobile.

How to use

1. Copy a PEM certificate block (from a server, a file, or openssl output) and paste it into the input area.
2. Alternatively paste a raw base64 DER certificate (without the -----BEGIN/END----- headers) — the tool detects either format automatically.
3. Click Inspect Certificate to decode all fields.
4. Review the table showing Subject, Issuer, SANs, validity dates, key info, and fingerprints.
5. Use the Copy as JSON button to export the decoded data for scripting or documentation.
6. Copy a PEM certificate block (from a server, a .crt/.pem file, openssl s_client output, or a CI artifact) and paste it into the input area.

When it helps

• Debugging TLS handshake failures by verifying certificate fields before deployment.
• Checking that a newly-issued certificate covers all required domains via the SAN list.
• Auditing certificates in a certificate transparency log or CA bundle.
• Verifying certificate fingerprints before pinning them in a mobile app.
• Monitoring expiry dates on certificates that lack automated renewal.
• Debugging TLS handshake failures by verifying certificate Subject and SAN fields before deployment.

Examples

-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgISA...
-----END CERTIFICATE-----

Subject CN: utilitykit.tools
Issuer: R3 (Let's Encrypt)
SANs: utilitykit.tools, www.utilitykit.tools
Valid: 2026-04-01 → 2026-06-30 (53 days remaining)
Key: ECDSA P-256
Sig: ECDSA with SHA-256
SHA-256: AB:CD:...

(PEM block of a *.example.com certificate)

SANs: *.example.com
Warning: example.com itself is not covered. Wildcard does not match the apex domain — you may need a separate cert or add example.com as an explicit SAN.

(PEM block expiring in 12 days)

Validity: 2025-12-01 → 2026-05-20 (12 days remaining) — orange banner displayed.
Action: schedule renewal; consider automating via ACME/cert-manager if not already.

Click Copy as JSON after inspecting any certificate.

{"subject":{"CN":"api.example.com","O":"Example Inc"},"issuer":{"CN":"R3"},"sans":["api.example.com"],"validFrom":"2026-04-01T00:00:00Z","validTo":"2026-06-30T23:59:59Z","daysRemaining":53,"keyAlgorithm":"ECDSA P-256","sigAlgorithm":"ecdsa-with-SHA256","sha256":"AB:CD:..."}

Tips

• The SHA-256 fingerprint in the output can be compared against the value shown in browser DevTools under Security > Certificate to confirm you are inspecting the same cert the browser sees.
• Certificates expiring in under 30 days show an orange banner — export the JSON and add a row to your monitoring spreadsheet or alerting system.
• For wildcard certificates, check the SAN list carefully — *.example.com does NOT cover example.com itself unless it is also listed as a separate SAN entry.
• Multi-SAN certs are common — verify every required domain appears in the SAN list before deploying, because missing domains will cause a NET::ERR_CERT_COMMON_NAME_INVALID in users' browsers.
• Use the Copy as JSON output as the body of an internal renewal ticket: it includes all key facts (SAN, issuer, expiry) in a copy-pasteable structured format.
• When pinning a fingerprint in a mobile app, prefer SHA-256 over SHA-1 — modern pinning libraries (TrustKit, Network Security Config) all support SHA-256 and SHA-1 is collision-prone.

Frequently Asked Questions

Glossary

PEM

Privacy Enhanced Mail — the base64-encoded form of a DER certificate surrounded by -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- headers, used in most server config files.

DER

Distinguished Encoding Rules — the binary ASN.1 encoding of an X.509 certificate. PEM is just DER base64-encoded with header lines added.

ASN.1

Abstract Syntax Notation One — the schema language used by X.509 to define certificate structure. ASN.1 is the underlying grammar; DER is one of its binary encodings.

SAN (Subject Alternative Name)

An X.509 extension listing all hostnames and IPs a certificate is valid for. Modern browsers require at least one SAN entry and ignore the Subject CN.

Key Usage

An X.509 extension that restricts what operations a certificate's public key may perform — digital signature, key encipherment, certificate signing, CRL signing, etc.

CA (Certificate Authority)

An entity that issues and signs certificates after verifying the requester's identity. Public CAs (Let's Encrypt, DigiCert, Sectigo) are trusted by browsers; private CAs serve internal use.

Fingerprint

A cryptographic hash (typically SHA-1 or SHA-256) of the entire certificate DER binary, used for identification, pinning, and out-of-band identity verification.

CN (Common Name)

A field in the X.509 Subject that historically identified the domain. Modern TLS relies on the SAN extension instead — CN is now mostly informational.