Parse PEM-encoded certificates, keys, and CSRs. Display algorithm, key size, subject, issuer, and validity details.
This tool takes one or more PEM blocks, strips the base64 body between the BEGIN/END markers, decodes it to DER, and walks the ASN.1 structure to surface subject, issuer, validity dates, signature algorithm, and public key type and size. It handles certificates, CSRs, and public/private keys as separate object types. The most common surprise: a chain file with several concatenated blocks is reported block by block, not merged into one certificate path, so users looking for 'the chain is valid' get individual field dumps instead.
A concrete input and expected output from the current implementation.
Input
-----BEGIN CERTIFICATE----- MIIB... -----END RSA PRIVATE KEY-----
Expected output
Error: mismatched PEM boundaries - block opens with 'BEGIN CERTIFICATE' but closes with 'END RSA PRIVATE KEY'. No fields extracted.
PEM requires the BEGIN and END labels of a block to match (RFC 7468); a parser that enforces this cannot treat the base64 payload as either object type and must reject the block rather than guess.
For each matched BEGIN/END pair the tool base64-decodes the body to raw DER, then walks the ASN.1 tag-length-value tree using the schema implied by the label: X.509 for CERTIFICATE, PKCS#10 for CERTIFICATE REQUEST, PKCS#1/PKCS#8/SEC1 for keys. Named fields (subject DN, validity, key parameters) are pulled from fixed positions in that schema rather than shown as raw hex.
Because a PEM file only carries a plain-text label, the parser picks its extraction schema from that label before looking at the DER content. A block whose label doesn't match its actual contents (a private key saved under a CERTIFICATE header, for instance) will be parsed under the wrong assumptions and produce an error or garbled fields rather than being auto-corrected.
No. It reads the fields inside each PEM block you give it - subject, issuer, validity, algorithm - but it does not build or validate a trust path against a CA store and does not check revocation status. For chain validation, use a tool that performs that check explicitly, such as openssl verify.
No, it parses one PEM input at a time and doesn't compare two files against each other. To check a match yourself, look at the public key details this tool reports for each file separately, or compare modulus/public key output the way openssl rsa -noout -modulus and openssl x509 -noout -modulus are typically compared.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.