Divisor de pacotes PEM (PEM Bundle Splitter)

What a PEM bundle is

PEM is the text form of DER: base64 between a -----BEGIN LABEL----- and an -----END LABEL----- line, defined for certificates and keys in RFC 7468. Because it is text, PEM blocks are easy to concatenate, and most real-world files are exactly that: a fullchain.pem from Let's Encrypt with the server certificate and its intermediate, a ca-bundle.crt from a reseller, a trust store like cacert.pem with a hundred roots, or the output of openssl pkcs12 -nodes with a private key, certificates and "Bag Attributes" lines in between.

Servers and libraries are less forgiving than the format. nginx wants the certificate and its chain in one file and the key in another; Apache and HAProxy differ; Java wants a keystore; a stray text line, Windows line endings or a key in the wrong file each produce their own cryptic error. This tool takes the bundle apart so that each piece can go where it belongs.

What the splitter does

Each block is found, decoded and identified by its content, not only by its label: certificates, certificate requests, CRLs, public keys, PKCS #8, PKCS #1 and SEC1 private keys, encrypted keys and PKCS #7 bundles. A label that does not match the content — the classic is a SEC1 EC key labelled PRIVATE KEY — is reported. For certificates you see the subject, the issuer, the expiry date and the key; for keys, the algorithm. Every block gets its SHA-256 fingerprint and a file name built from its content (01-www-example-com.crt, 04-private-key-rsaencryption.key), and is re-wrapped in strict RFC 7468 form: 64-character lines, LF line endings, no headers or surrounding text. Text between blocks is reported and dropped.

A binary .p7b (PKCS #7 "certs-only") file or a DER certificate can be dropped too; its certificates are unpacked into PEM first, which is the quickest way to turn a Windows certificate export into something nginx accepts.

The chain in server order

A TLS server must send its certificate first, then the certificate that issued it, then that one's issuer — RFC 8446 §4.4.2 for TLS 1.3, RFC 5246 for TLS 1.2. Clients that receive a chain out of order or with a gap fail with errors like "unable to verify the first certificate" or "PKIX path building failed". The splitter links the certificates by issuer and subject names, finds the end certificate, and proposes the chain in that order, ready to copy or download as chain.pem. It tells you whether the bundle already had that order, which certificates are not on the chain — often a second, cross-signed version of an intermediate — and whether the chain ends with a self-signed root, which servers usually leave out because clients already trust it.

When the certificates are a trust store, or several unrelated chains, no order is proposed; the certificates are still listed and available as one clean file.

Private keys and what runs where

Splitting, decoding and hashing happen in your browser; nothing you paste is sent anywhere. A bundle that contains a private key gets a warning, the key's PEM is shown only when you ask for it, and its fingerprint is not displayed. Share links carry the bundle in the URL fragment, which browsers do not send to servers, and the page removes private key blocks before it builds one — the codec would refuse the link otherwise. If you open a .pfx file instead of PEM, use the PFX inspector; to read one certificate in depth, the certificate decoder.