SSL/TLS Certificate Inspector
Paste any PEM certificate block to extract issuer, subject, Subject Alternative Names (SANs), validity dates, fingerprint, key algorithm and extensions — entirely in your browser using forge.js. Nothing is sent to any server.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -outform PEMThen paste the PEM output above.
node-forge library running entirely in your browser. Your certificate data never leaves your device.
What is an SSL Certificate Inspector?
An SSL/TLS certificate inspector parses X.509 certificate data and presents it in a human-readable format, revealing details that are buried in the raw certificate encoding. DevOps and SRE engineers use certificate inspection to verify deployments, diagnose TLS handshake failures, and audit certificate hygiene before issues cause production incidents. Rather than using command-line tools like openssl x509 -text, this browser-based inspector gives you the same information instantly without leaving your workflow.
SSL certificates are foundational to web security — they authenticate server identity and establish encrypted channels. Misconfigured or expired certificates cause immediate user-facing outages, browser security warnings, and broken API integrations. Proactively inspecting certificates during deployment and before expiry dates is a core SRE practice for maintaining HTTPS reliability.
When to Use This Tool
- Verifying a new certificate deployment: After installing a certificate on a web server, inspect it to confirm the correct subject, SANs, validity period, and issuer chain are in place before directing traffic to the server.
- Debugging TLS handshake errors: When clients report SSL errors, paste the server's certificate to check for expired validity, hostname mismatches between the CN/SANs and the requested domain, or unexpected issuer chains.
- Auditing certificate expiry across services: Review expiry dates for all certificates in your infrastructure to identify those approaching renewal deadlines, preventing unexpected outages from expired certs.
- Validating Let's Encrypt and ACME certs: Inspect automatically issued certificates after ACME renewal to confirm the SAN list is correct and the certificate was issued by the expected CA before the old cert is revoked.
How It Works
The inspector uses the forge.js library to parse PEM-encoded X.509 certificates entirely within the browser. PEM (Privacy Enhanced Mail) is a Base64-encoded DER (Distinguished Encoding Rules) binary format wrapped in -----BEGIN CERTIFICATE----- headers. The parser extracts the ASN.1 structure of the certificate, decoding fields including the subject distinguished name, issuer, serial number, validity window, public key algorithm and bit-length, signature algorithm, and the Subject Alternative Names extension. No certificate data is transmitted to any server during this process.
Frequently Asked Questions
What certificate formats does this tool support?
This tool accepts PEM-encoded X.509 certificates — the format that begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----. PEM is the most common certificate format used by web servers (nginx, Apache, Caddy), certificate authorities like Let's Encrypt, DigiCert, and Sectigo, and cloud platforms like AWS ACM, GCP Certificate Manager, and Azure Key Vault. If your certificate is in DER binary format or PKCS#12 (.p12/.pfx), you can convert it to PEM using openssl x509 -inform der -in cert.der -out cert.pem before pasting it here.
Is it safe to paste my SSL certificate here?
Yes, it is completely safe. SSL/TLS certificates are intentionally public — every browser that connects to an HTTPS website receives and processes the server's certificate as part of the TLS handshake. The certificate contains only public information: the domain name, issuer, validity dates, and public key. The corresponding private key, which must always remain secret, is a completely separate file and is never embedded in the certificate. This tool processes your certificate exclusively in your browser using JavaScript — no data leaves your machine.
What are Subject Alternative Names (SANs) and why do they matter?
Subject Alternative Names (SANs) are the definitive list of domain names and IP addresses that a certificate is authorised to secure. Modern browsers and TLS clients rely exclusively on SANs to validate whether a certificate is valid for the hostname being accessed — the older Common Name (CN) field is no longer recognised for hostname validation per RFC 2818. A wildcard SAN like *.example.com covers all immediate subdomains (app.example.com, api.example.com) but does not cover sub-subdomains (v2.api.example.com) or the apex domain (example.com) itself. Inspecting SANs is the first diagnostic step when investigating ERR_CERT_COMMON_NAME_INVALID or similar certificate mismatch errors.