PEM Certificate Viewer
Inspect PEM certificates for boundaries, X.509 fields, validity, SANs, algorithms, and fingerprints without claiming trust validation.
Accepts certificate, certificate-request, public-key, private-key, CRL, and other RFC 7468-style PEM blocks. Avoid unnecessary handling of production private keys.
PEM boundaries, decoded size, SHA-256 fingerprint, and available X.509 certificate fields will appear here.
PEM Is the Envelope; DER and ASN.1 Explain What Is Inside It
The familiar BEGIN/END lines do not themselves contain certificate fields. RFC 7468 describes a textual envelope whose body is Base64 representing binary structures such as X.509 certificates, public keys, certificate requests, CRLs, PKCS #8 private keys, and CMS objects.
An X.509 certificate is normally represented in PEM by wrapping its DER-encoded ASN.1 Certificate value. The parser first verifies the envelope and Base64, then walks enough DER structure to expose the certificate fields that are most useful during debugging.
RFC 7468 also documents deliberately tolerant parser behavior found in deployed software. Yoryantra uses a stricter Base64 body check so contamination or malformed padding is visible during inspection instead of being silently ignored. A legacy application can therefore accept input that this diagnostic viewer asks you to clean up.
A Fingerprint Belongs to the Exact DER Bytes, Not to the Subject Name
Two certificates can contain the same subject Common Name and still be completely different certificates. Their serials, issuers, validity windows, public keys, extensions, and signatures can all differ.
The SHA-256 fingerprint on this page hashes the entire decoded certificate DER value. When two independently obtained certificate copies have the same fingerprint, their encoded certificate bytes match. That still does not prove the certificate is trusted for your connection.
Subject and Issuer Names Are Helpful Labels, Not Hostname Validation
X.509 names can contain Common Name, organization, country and other attributes. For modern TLS hostname checks, the Subject Alternative Name extension is the important place to inspect DNS names and IP addresses.
Even seeing DNS:example.com in the SAN list is not a complete hostname-validation result. Wildcard rules, IDNA handling, name constraints, the exact requested hostname, path validation and trust all belong to the TLS/certificate-validation layer.
“Not Expired” Is Only One Condition in Certificate Validation
The browser clock can show whether the current time falls between the encoded notBefore and notAfter values. That is useful operational information, but a certificate inside its time window can still fail because the chain is untrusted, a signature is invalid, the hostname is wrong, the certificate is revoked, an extension disallows the use, or an intermediate is missing.
Treat the validity badge as “inside encoded dates according to this device clock,” not as “certificate valid.”
A Certificate Chain Is More Than Several CERTIFICATE Blocks in a File
TLS deployments often concatenate a leaf certificate with one or more intermediate CA certificates. A PEM file can therefore contain several CERTIFICATE blocks. The order matters to some server configurations, and the chain has cryptographic relationships that cannot be proven from labels alone.
Each certificate is shown independently. The browser-side inspection does not verify that certificate 1 was signed by certificate 2, build alternate paths to a trust anchor, or decide which root store a client uses. Use a real X.509 path validator or TLS client for those questions.
Basic Constraints Help Distinguish CA Certificates From Ordinary End-Entity Certificates
The X.509 Basic Constraints extension contains a CA boolean and can optionally limit certification-path depth. A CA certificate used to sign other certificates normally needs the CA assertion and related key-usage semantics.
The parser decodes the common Basic Constraints shape when present. It does not evaluate the full interaction of Basic Constraints, Key Usage, Extended Key Usage, Name Constraints, policy extensions, critical-extension processing and the certificate path.
Private-Key PEM Blocks Deserve a Different Handling Rule
A certificate is designed to be shared. A private key is not. Browser-local processing reduces one category of exposure, but copying production key material into an unnecessary tool still increases the chance of leakage through clipboard history, screenshots, screen sharing, browser extensions, local logging, or accidental reuse in examples.
If a private-key block is pasted, Yoryantra reports its envelope, byte length and fingerprint but deliberately avoids a decoded-byte preview. Use purpose-built key tooling when you need key consistency or public/private matching.
Why a PEM File Can Open Successfully in One Tool and Fail in Another
RFC 7468 documents real-world parser variation around whitespace, labels, explanatory text and encapsulation formatting. On top of that, applications expect different inner structures: a web server may expect a certificate chain in one file and an unencrypted private key in another, while a Java workflow might use PKCS #12 instead.
When a PEM envelope looks correct but an application rejects it, verify the expected block label, the decoded object type, encryption requirements, key pairing, chain order, and the application's own file-format documentation.
Defines textual encapsulation boundaries and Base64 conventions for certificates, CRLs, CSRs, public/private keys and related PKIX/PKCS/CMS structures.
Defines the Internet X.509 certificate and CRL profile, including certificate fields, extensions, validity and path-validation requirements.