UtilityKit

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

X.509 Certificate Inspector

Decode PEM or DER (base64) X.509 certificates to extract subject, issuer, SANs, validity, key info, and fingerprints.

About X.509 Certificate Inspector

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 X.509 Certificate Inspector

No openssl binary needed

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

Expiry countdown highlights certificates

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

Shows SANs in full

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

JSON export enables pasting

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

Completely offline-capable

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

No openssl binary needed

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

How to use X.509 Certificate Inspector

  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).
  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.
  7. Alternatively paste a raw base64 DER certificate (without the -----BEGIN/END----- headers) — the tool detects either format automatically.

When to use X.509 Certificate Inspector

  • 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

Inspecting a Let's Encrypt server certificate

Input: -----BEGIN CERTIFICATE----- MIIFazCCBFOgAwIBAgISA... -----END CERTIFICATE-----

Output: 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:...

Spot-checking a wildcard certificate's SAN coverage

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

Output: 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.

Detecting a near-expiry certificate during an audit

Input: (PEM block expiring in 12 days)

Output: 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.

Capturing certificate metadata as JSON for a runbook

Input: Click Copy as JSON after inspecting any certificate.

Output: {"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

What is the difference between PEM and DER format?▾
DER (Distinguished Encoding Rules) is the binary form of an X.509 certificate. PEM (Privacy Enhanced Mail) is the same data base64-encoded and wrapped in -----BEGIN CERTIFICATE----- headers — the format you usually see when copying certificates from servers or files.
How do I get a certificate in PEM format from a live server?▾
Run: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -out cert.pem — then paste the contents of cert.pem here. Alternatively use the TLS Certificate Checker tool which fetches and decodes live server certificates automatically.
What are Subject Alternative Names (SANs)?▾
SANs are the list of hostnames and IP addresses that a certificate is valid for. Modern browsers ignore the Subject CN field and only trust the SAN list. A wildcard SAN like *.example.com covers all immediate subdomains but not sub-subdomains.
What is a certificate fingerprint used for?▾
A fingerprint is a hash (SHA-1 or SHA-256) of the entire certificate. It lets you verify that a certificate you receive matches a known-good copy without reading every field — commonly used in certificate pinning and manual trust decisions.
Why does my certificate show a different CN than the domain I expected?▾
Many certificates issued by commercial CAs use the organization name or a generic string in the CN field and list actual domains in the SAN extension. Always check the SAN list to see which hostnames the certificate actually covers.
Can I inspect code-signing or client certificates here?▾
Yes. Any PEM or DER X.509 certificate can be parsed, including client certificates, code-signing certificates, and CA intermediate certificates. The tool displays all standard fields regardless of certificate purpose.

Explore the category

Base64 Encode and decode Base64 strings Data URL Builder Build and decode data URLs with MIME, charset, and Base64 options. RSA Key Generator Issue RSA-OAEP 2048 PEM pairs via Web Crypto. MongoDB ObjectId Generator Generate MongoDB-compatible ObjectIds and decode existing ones to extract their embedded timestamp, machine, and counter fields. SSH Public Key Fingerprint Calculate the MD5 and SHA-256 fingerprints of an SSH public key to verify identity without sharing the full key. JWT Decoder Decode and inspect JWT tokens
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 How PGP Encryption Works: Keys, Trust, and Real-World Use PGP (and OpenPGP) has secured email and files since 1991. We explain key pairs, the web of trust, signing vs encrypting, and where PGP still Mar 2026 · 8 min

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.