{{ block.index }}. {{ block.type }}
{{ block.pem }}{{ block.pem }}| # | Type | Lines | Bytes | SHA-256 | Filename | Copy |
|---|---|---|---|---|---|---|
| {{ row.index }} | {{ row.type }} | {{ row.line_span }} | {{ formatNumber(row.byte_count) }} | {{ row.sha256_preview }} | {{ row.filename }} |
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.
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.
Start with the unedited source so block order, unmatched markers, and line positions remain meaningful.
BEGIN and END labels instead of renaming one by guesswork.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.
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.
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.
| 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. |
| Label pattern | Class | Filename form |
|---|---|---|
CERTIFICATE | Certificate | cert_XX.crt |
Contains CERTIFICATE REQUEST | CSR | csr_XX.csr |
Contains PRIVATE KEY or PUBLIC KEY | Key | key_XX.key |
Contains PKCS7 | Other | bundle_XX.p7b |
| Any other matching label | Other | pem_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.
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.
ENCRYPTED PRIVATE KEY label indicates encrypted material; extraction neither requests nor tests its passphrase.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.