100% Client-Side • Air-Gapped Engine
No private keys or certificates leave your browser
Paste Certificate, CSR, or PEM Bundle
CSR — CERTIFICATE SIGNING REQUEST
SERVER CERTIFICATE (END-ENTITY)
Certificate Chain:
Enterprise X.509 Certificate & TLS Architecture Guide
Digital certificates built upon the ITU-T X.509 v3 specification (RFC 5280) form the foundational trust anchor for internet security, software-defined datacenters, and enterprise virtualization. Understanding how modern cryptographic standards govern certificate fields is essential for infrastructure engineers, security administrators, and network architects.
How the SSL TLS Decoder Parses ASN.1 DER & PEM Structures
An SSL TLS decoder decomposes ASN.1 Distinguished Encoding Rules (DER) and Base64 PEM containers into RFC 5280 objects. When troubleshooting enterprise web services across HTTPS port 443 & TLS handshake protocols or securing LDAP directories on port 636, this decoder extracts the exact public key parameters, certificate serial number, and signature algorithm directly in browser memory without sending private data over the wire.
Using the SSL Certificate Checker for Expiry Timers & SAN Coverage
Proactive infrastructure monitoring requires verifying expiration timestamps and endpoint coverage before production outages happen. Our integrated SSL certificate checker highlights two critical compliance requirements:
1. The Subject Alternative Name (SAN) Mandate
RFC 2818 and RFC 6125 formally deprecated using the Subject Common Name (CN) for domain identity
validation. Modern web browsers (including Chromium 58+, Firefox, and Safari) completely disregard the CN
attribute if SANs are present, and throw severe certificate validation errors if the SAN extension is
missing. A valid server certificate must enumerate all target DNS hostnames and IP addresses inside the
SAN extension.
2. The 398-Day Public Validity Boundary
Following ballot SC31 of the CA/Browser Forum, all public TLS certificates issued after September 1, 2020
are capped at a maximum lifetime of 398 days (825 days previously). Certificates exceeding this window are
marked invalid by iOS, macOS, and Android. When coordinating certificate renewals across global datacenters, engineers use our Maintenance Window & Timezone Scheduler to prevent service interruption.
3. VMware vSphere & ESXi Compatibility
VMware vCenter Server (vSphere 7/8) utilizes Machine SSL certificates for reverse proxy (rhttpproxy) and
VMware Authentication Services (STS). VMware STS strictly requires that both the Fully Qualified Domain
Name (FQDN) and the appliance's management IPv4/IPv6 address be included in the SAN extension. Cross-reference firewall access with our VMware Ports & Protocols Cheatsheet.
4. PKCS#10 CSR Cryptographic Verification
A CSR acts as the formal mathematical application for a digital certificate. Standardized under RFC 2986
(PKCS#10), it bundles the subject identity, public key, and requested X.509 v3 extensions with a digital
signature generated using the applicant's private key. Verifying this self-signature guarantees private
key possession without leaking the private key itself.
Common X.509 v3 Extensions & Security Implications
Extensions allow X.509 certificates to declare constraints and allowed operational scopes. Misconfiguring extensions can cause severe outages across VMware clusters, Kubernetes API servers, or reverse proxies:
- Basic Constraints (
2.5.29.19): Distinguishes whether the certificate is a Certificate Authority (cA: TRUE) capable of issuing subordinate certificates, or an End-Entity / Leaf server certificate (cA: FALSE). If a leaf certificate is incorrectly marked as a CA, modern operating systems trigger untrusted certificate warnings. - Key Usage (
2.5.29.15): Defines cryptographic capabilities. Web server TLS certificates mandate Digital Signature and Key Encipherment (or Key Agreement for ECC). Intermediate CAs require Certificate Signing (keyCertSign) and CRL Signing. - Extended Key Usage (
2.5.29.37): Specifies application purposes. Web servers require Server Authentication (1.3.6.1.5.5.7.3.1). For mutual TLS (mTLS), VMware vSphere Solution Users, and smart card authentication, Client Authentication (1.3.6.1.5.5.7.3.2) is also mandatory.
HOW TO USE
CSR & Certificate Decoder
- Paste or upload your certificate or CSR — paste any PEM-encoded certificate, CSR,
or bundle into the text area, or click Upload File to select a
.crt,.cer,.pem,.csr,.der, or.p7bfile. Drag and drop is also supported. - Inspect the live cryptographic breakdown — the decoder immediately parses the ASN.1 structure, displaying the Subject DN, Issuer authority, Serial Number, Signature Algorithm, Public Key size, and WebCrypto SHA-256 fingerprints.
- Validate expiration ticker & SAN coverage — monitor days remaining with a real-time progress bar, verify browser trust requirements, and cross-reference Subject Alternative Names (SANs) against VMware vSphere / ESXi compatibility matrices.
- Export compliance documentation — download formatted PEM assets, export structured JSON telemetry, or print an air-gapped cryptographic audit report directly from your browser.
Privacy & DLP Note: 100% of cryptographic decoding runs locally
inside your browser memory via WebCrypto APIs. If your organization operates under strict DLP monitoring,
follow our OpenSSL Commands Guide below.
CSR vs Certificate Comparison
- Provide both CSR and Server Certificate — paste your original CSR (Certificate Signing Request) into the left box and your issued end-entity SSL certificate into the right box.
- Click Compare & Match — the engine calculates the public key modulus hashes for both structures to verify 100% mathematical keypair identity.
- Verify field fidelity — confirm that all Subject fields (CN, Organization, Organizational Unit, Country, State, Locality) and SANs requested in the CSR were accurately signed into the certificate without omissions or unauthorized alterations by the CA.
Important: Do not paste an Intermediate or Root CA certificate in the
certificate field — only paste the server leaf certificate issued specifically for your domain.
X.509 & CSR Cryptographic Specification Matrix (EAV)
Standardized Entity-Attribute-Value (EAV) architectural parameters mapped to authoritative IETF RFCs and CA/Browser Forum guidelines.
| Entity (E) | Architectural Attribute (A) | Definitive Value / Standard (V) | Governing Authority |
|---|---|---|---|
| X.509 v3 Certificate | Binary Data Serialization | ASN.1 DER (Distinguished Encoding Rules) | ITU-T X.690 / RFC 5280 |
| PEM ASCII Armor | Base64 Encapsulation Boundary | -----BEGIN CERTIFICATE----- |
RFC 7468 §5.1 |
| PKCS#10 CSR | Signing Request Structure | certificationRequestInfo + Signature |
RFC 2986 / PKCS #10 |
| Endpoint Identity | Domain & IP Validation Anchor | subjectAltName (dNSName, iPAddress) |
RFC 6125 / RFC 2818 |
| Validity Lifetime | Public TLS Expiration Ceiling | 398 Days (34,387,200 seconds) | CA/B Forum SC31 |
| Public Key Cryptography | Minimum Asymmetric Key Size | RSA ≥ 2048-bit / ECC ≥ 256-bit (P-256) | NIST SP 800-57 Part 1 |
| vSphere Machine SSL | Mandatory SAN Topology | FQDN DNS + NetBIOS Hostname + IPv4 SAN | VMware KB 2015387 |
| Cryptographic Fingerprint | Collision-Resistant Hash Identifier | SHA-256 (32 bytes) / SHA-1 Legacy | W3C WebCrypto API |
Offline OpenSSL Administrator Runbook & CLI Command Matrix
Zero-Browser Terminal ExecutionFor security-conscious engineers operating under strict enterprise DLP policies, air-gapped jump boxes, or isolated VMware datacenters, terminal-native OpenSSL commands allow complete offline inspection and verification without touching a web browser or triggering clipboard surveillance:
OpenSSL Commands for Offline Certificate Decoding & Expiration Checking
1. Decode Full Certificate Details (Subject, Issuer,
Validity & Extensions)
X.509 Inspection
openssl x509 -in cert.pem -text -noout
2. Check Expiration Date & Verify If Expiring
Within 30 Days
Lifecycle Monitoring
openssl x509 -in cert.pem -noout -enddate
# Exit code 0 if valid for at least 30 days (2,592,000s); exit code 1 if expiring soon or expired:
openssl x509 -checkend 2592000 -noout -in cert.pem
3. Extract Subject Alternative Names (SANs)
Only
SAN Extraction
openssl x509 -in cert.pem -noout -ext subjectAltName
4. Compute SHA-256 and SHA-1 Thumbprints
(Fingerprints)
Cryptographic Hashes
openssl x509 -in cert.pem -noout -fingerprint -sha256
openssl x509 -in cert.pem -noout -fingerprint -sha1
5. Inspect CSR & Verify Private Key
Self-Signature (PKCS#10)
CSR Verification
openssl req -in request.csr -text -noout -verify
Verifying Private Key Modulus & CSR Matching via OpenSSL CLI
6. Verify That Certificate Matches Private Key
(Modulus Hash Comparison)
Keypair Integrity
openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5
7. Probe Live Remote TLS Handshake & Dump Full
Certificate Chain
Live Handshake
openssl s_client -connect vcenter.corp.local:443 -servername vcenter.corp.local
-showcerts
8. Convert Binary DER to Base64 PEM (and Vice
Versa)
Format Transcoding
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM
openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
Frequently Asked Questions: SSL TLS Decoder & Certificate Checker
Yes, 100% safe. This SSL TLS decoder operates exclusively inside your local browser memory using JavaScript WebCrypto APIs and client-side ASN.1 parsing. No certificate strings, server hostnames, internal IP addresses, or metadata are ever transmitted across the network. All cryptographic telemetry is computed locally with zero server-side telemetry. The only sensitive component in an SSL deployment is the private key, which this tool never requests, reads, or stores.
An SSL certificate checker validates an X.509 certificate's cryptographic properties, validity window, and trust hierarchy. It confirms that the certificate is currently active, has not exceeded the CA/B Forum 398-day validity limit, and computes an exact expiration countdown timer. Running an SSL certificate check prior to deploying to reverse proxies, load balancers, or vSphere hosts prevents unexpected downtime and fatal
ERR_CERT_DATE_INVALID browser errors.
A Certificate Signing Request (CSR) is a PKCS#10 file generated on your server containing
your public key and identity attributes (domain name, organization, country). You submit it to a Certificate
Authority (CA). The CA verifies your organization and issues a signed X.509 certificate,
which combines your public key with a validity period, serial number, CA digital signature, and v3 extensions.
The CSR itself is discarded after certificate issuance.
RFC 2818 and RFC 6125 formally deprecated relying on the Subject Common Name (CN) for domain validation. All
modern browsers (Chromium 58+, Safari, Firefox) mandate that target hostnames and IP addresses exist in the
Subject Alternative Name (SAN) extension. If a certificate lacks SANs, modern clients reject
it immediately with
NET::ERR_CERT_COMMON_NAME_INVALID errors. Our SSL certificate checker lists every SAN, separates DNS from IP addresses, and flags wildcard domains.
This SSL TLS decoder accepts all standard PEM ASCII-armored blocks with
-----BEGIN ...----- headers, including CERTIFICATE, CERTIFICATE REQUEST, X509 CERTIFICATE, and PKCS7 bundles. Binary DER files (.der, .crt, .cer) can be uploaded directly via the file picker. The parser unpacks multi-cert P7B chains automatically. Encrypted PKCS#12/PFX bundles are excluded to uphold zero-leakage security boundaries.
A certificate fingerprint is a cryptographic hash (computed via SHA-256 or legacy SHA-1) of the complete
DER-encoded certificate binary. It acts as a unique mathematical identifier used for certificate pinning,
lookup in Certificate Transparency (CT) logs, and verifying that deployed server certificates match authorized
baselines without modification.
A modulus mismatch occurs when: (1) an older or alternate CSR was pasted instead of the one submitted to the CA;
(2) an Intermediate or Root CA certificate was pasted instead of the server leaf certificate; or (3) the server
private key was regenerated after CSR creation. The CSR and certificate must share the exact cryptographic
public key modulus to form a valid pair.
Web browsers establish trust by walking up the certificate chain: from the leaf server certificate, through
one or more Intermediate CAs, to a trusted Root CA pre-installed in the OS trust store. If a web server fails
to serve the Intermediate CA bundle alongside its leaf certificate, clients throw
SEC_ERROR_UNKNOWN_ISSUER
warnings. Our decoder visualizes the multi-tier hierarchy to ensure proper chain assembly.
Key Usage declares low-level cryptographic functions (e.g., Digital Signature, Key Encipherment,
or Certificate Signing for CAs). Extended Key Usage (EKU) declares higher-level application purposes,
such as Server Authentication (
1.3.6.1.5.5.7.3.1) for HTTPS and Client Authentication (1.3.6.1.5.5.7.3.2)
for mTLS, smart cards, and VMware STS solutions.
VMware vCenter Server Appliance (VCSA) certificate replacement scripts and the vSphere Certificate Manager
mandate that the Machine SSL certificate include:
- The Fully Qualified Domain Name (FQDN) as a DNS SAN (e.g.,
vcenter.corp.local). - The short NetBIOS / hostname as a DNS SAN (e.g.,
vcenter). - The management IPv4 address as an IP SAN (e.g.,
192.168.1.50). - Optionally, the IPv6 address if dual-stack networking is active.
You can compare the cryptographic modulus of the public key inside the certificate with the modulus of the
private key using these OpenSSL commands:
openssl x509 -noout -modulus -in cert.pem | openssl md5 openssl rsa -noout -modulus -in private.key | openssl md5If both MD5 hash outputs are identical, the certificate and private key form a verified cryptographic pair.
Discussion 0
Author Active`command`for inline code