{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ summaryTypeBadge }} {{ summaryPairBadge }} {{ summaryHashBadge }}
PEM bundle extraction source
Paste or load one bounded PEM bundle. Source text, certificates, CSRs, and keys stay in this browser and are never added to the share URL.
{{ sourceError }}
{{ fileStatus || 'Drop one PEM, CRT, CER, CSR, KEY, PUB, or TXT file onto the textarea.' }}
{{ workflowFeedback }}
Letters, numbers, dots, underscores, and hyphens are retained; blank keeps names such as cert_01.crt.
Sixteen characters is the neutral default; full SHA-256 values remain in the inventory export.
{{ blockExportStatus }}

{{ block.index }}. {{ block.type }}

Lines {{ block.line_span }} · {{ formatNumber(block.byte_count) }} bytes · SHA-256 {{ block.sha256_preview }}
{{ block.details }}
{{ block.pem }}
{{ tableExportStatus }}
#TypeLinesBytesSHA-256FilenameCopy
{{ row.index }}{{ row.type }}{{ row.line_span }}{{ formatNumber(row.byte_count) }}{{ row.sha256_preview }}{{ row.filename }}
{{ chartExportStatus }}

A copied certificate bundle can contain several cryptographic objects that look almost identical at a glance. The dependable landmarks are the encapsulation boundaries: a line beginning with -----BEGIN , a label, and a matching -----END line. Everything between those boundaries belongs to one text-wrapped object.

Privacy-Enhanced Mail (PEM) is commonly used as a text envelope for certificates, certificate signing requests, public keys, private keys, and other Public Key Infrastructure (PKI) structures. The body is usually base64-encoded binary data. Its label identifies the intended structure, but does not prove that the content is valid, trusted, current, or paired with the correct key.

Certificate
An X.509 identity document containing a public key, subject, issuer, validity interval, and extensions.
Certificate signing request
A PKCS #10 request that carries a subject and public key and is signed by the requester.
Key block
Public or private key material. A private-key block remains sensitive even when encrypted.
Certificate chain
Several certificate blocks kept in an order meaningful to the server or client that consumes them.

Splitting is useful during certificate renewal, proxy configuration, incident review, and handoff between systems. Source order and line spans help reconstruct where every object came from. Byte counts and SHA-256 digests help distinguish blocks that share the same label or subject name.

The consequential mistake is treating successful extraction as certificate validation. Matching boundaries can surround malformed base64, an expired certificate, the wrong chain order, an unrelated private key, or a CSR for the wrong name. Extraction establishes boundaries and evidence; certificate, chain, hostname, key-pair, and trust checks remain separate jobs.

Preserve the original bundle until the split objects have been reviewed. Reordering certificates or deleting a block too early can remove the evidence needed to diagnose a failed deployment.

How to Use This Tool:

Start with the unedited source so block order, unmatched markers, and line positions remain meaningful.

  1. Paste text into PEM bundle, drop a supported text or certificate file, or use Browse. A local file larger than 2 MB is rejected, and parsed text is limited to 500,000 characters.
  2. Check the summary for the number of complete blocks, distinct labels, unmatched markers, and the source SHA-256 value. If no complete pair appears, restore the exact matching BEGIN and END labels instead of renaming one by guesswork.
  3. Use Block inventory to compare type, source lines, byte count, digest preview, and any decoded certificate, CSR, or RSA-key details. An unmatched-marker warning means the recovered rows are only the complete subset of the supplied text.
  4. Set Filename prefix or a longer Fingerprint preview only when those display and naming choices help the handoff. Neither option changes the recovered PEM text or the full digest.

Interpreting Results:

Extraction ready means at least one complete boundary pair was found and its evidence was recorded. Complete blocks with unmatched markers means usable pairs were recovered, but one or more starting markers had no matching recovered block.

Use line spans and full SHA-256 values to compare the extracted text with the original source. The digest is calculated over the normalized PEM text of the block, not over decoded DER bytes, so it is not interchangeable with a certificate fingerprint produced by other software.

Decoded details are clues rather than verdicts. A CSR signature check only shows that the request is internally signed by its embedded public key. Certificate common names, issuers, expiry dates, and RSA sizes do not establish trust, hostname coverage, revocation status, or chain order.

Technical Details:

RFC 7468 textual encodings use five hyphens, BEGIN or END, one space, and a label. A strict generator uses the same label on both boundaries. Multiple encodings may appear in one file, and their order can matter to the receiving system.

Transformation Core:

The extraction path is deliberately narrower than full PKI validation. It isolates complete pairs first, then adds classification and evidence without rewriting the block content.

Stages used to split and inspect PEM blocks
Stage Rule Result
Normalize source Trim outer whitespace, then count characters, lines, bytes, and starting markers. Bundle scope and a SHA-256 digest of the normalized source.
Pair boundaries Keep only the shortest complete region whose ending label exactly matches its starting label. Ordered blocks with original start and end line numbers.
Classify label CERTIFICATE becomes a certificate; labels containing CERTIFICATE REQUEST become CSRs; labels containing PRIVATE KEY or PUBLIC KEY become keys; all others remain other PEM objects. Type counts and a safe filename extension.
Inspect supported content Attempt certificate, CSR, and RSA-key parsing without discarding blocks that do not decode. Subject, issuer, expiry, RSA size, CSR signature status, encryption clue, or a structure-not-decoded note.
Attach evidence Count UTF-8 bytes and decoded body bytes, then hash the exact normalized block text with SHA-256. Comparable size and digest values for every recovered row.
PEM label classification and generated filename rules
Label pattern Class Filename form
CERTIFICATECertificatecert_XX.crt
Contains CERTIFICATE REQUESTCSRcsr_XX.csr
Contains PRIVATE KEY or PUBLIC KEYKeykey_XX.key
Contains PKCS7Otherbundle_XX.p7b
Any other matching labelOtherpem_XX.pem

A filename prefix is lowercased, limited to 40 characters, and reduced to letters, digits, periods, underscores, and hyphens. Other characters become underscores. This naming policy cannot identify a certificate or key and should not replace an inventory ID.

At most 100 complete blocks are accepted. The visible digest preview may show 8 to 32 hexadecimal characters in steps of four, while the underlying SHA-256 value remains 64 hexadecimal characters. A short preview is convenient for scanning but provides less collision resistance than comparing the full digest.

Privacy Notes:

PEM text and selected files are processed in the browser and are not sent to a server by this extraction workflow. That local path reduces transmission risk, but it does not make private-key handling harmless.

  • Avoid pasting production private keys into shared screens, recordings, tickets, or untrusted browser sessions.
  • Downloaded split files and copied values remain sensitive wherever the operating system, clipboard manager, browser downloads, or backup software stores them.
  • An ENCRYPTED PRIVATE KEY label indicates encrypted material; extraction neither requests nor tests its passphrase.

Worked Examples:

Chain bundle with an unfinished key block

A deployment note contains two complete CERTIFICATE blocks followed by a BEGIN PRIVATE KEY line with no matching end marker. The inventory recovers the two certificates in source order and reports one unmatched marker. Keep the original note, remove the incomplete secret from the handoff, and verify the two recovered certificates as a chain before installation.