PEM Bundle Splitter
Split a PEM bundle into individual certificates
PEM Bundle
Paste a PEM bundle to split it into individual items
Supported PEM Types
Certificates, private keys (RSA, EC, PKCS#8), public keys, CSRs, and CRLs. Click any item to preview, or click the type badges to copy all items of that type.
The PEM Bundle Splitter separates a file containing multiple concatenated PEM certificates into individual certificates, identifying the end-entity, intermediate, and root certificates in the chain -- essential for debugging TLS chain issues and extracting specific certificates from bundles. Paste a PEM bundle with multiple -----BEGIN CERTIFICATE----- blocks and get each certificate individually with its subject and issuer identified.
Understanding Certificate Bundles and Chains
When you set up TLS on a web server, you do not just install a single certificate. You need a chain of certificates that links your server's leaf certificate back to a root CA that clients trust. The leaf certificate says "I am example.com, and I was signed by Intermediate CA R3." The intermediate certificate says "I am R3, and I was signed by ISRG Root X1." The root certificate says "I am ISRG Root X1, and I signed myself." Clients verify this chain from bottom to top, and if any link is missing or broken, the connection fails.
Certificate Authorities typically deliver these certificates as a single PEM file with multiple certificate blocks concatenated together -- a bundle. Sometimes the bundle is in the right order, sometimes it is not, and sometimes it includes certificates you do not need (like the root, which clients already have). The problem is that a PEM bundle is just a wall of base64 text with repeating BEGIN/END markers, and it is nearly impossible to tell which certificate is which by looking at the raw text.
This splitter solves that problem. Paste your bundle and the tool separates each certificate, parses its subject and issuer fields, and labels it as leaf, intermediate, or root. You can then inspect each certificate individually, reorder them, remove unwanted ones, or copy specific certificates for use in different configurations. It is an essential debugging tool when you get a "certificate not trusted" or "unable to verify the first certificate" error and need to figure out what is actually in your chain file.
How to Split a PEM Certificate Bundle
- Paste your PEM bundle containing multiple
-----BEGIN CERTIFICATE-----blocks - The tool identifies and separates each certificate in the bundle
- Review the parsed subject and issuer for each extracted certificate
- Copy or download individual certificates as needed
Example: Splitting a Three-Certificate Chain
Input -- a concatenated PEM bundle:
-----BEGIN CERTIFICATE-----
MIIFjTCCBHWgAwIBAgIS... (leaf certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIR... (intermediate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQ... (root)
-----END CERTIFICATE-----
Output -- three individually identified certificates:
| # | Type | Subject | Issuer |
|---|---|---|---|
| 1 | End-entity | CN=www.example.com | CN=R3, O=Let's Encrypt |
| 2 | Intermediate | CN=R3, O=Let's Encrypt | CN=ISRG Root X1 |
| 3 | Root | CN=ISRG Root X1 | CN=ISRG Root X1 (self-signed) |
When to Use This Tool
- Debugging TLS handshake failures -- split a chain to identify missing intermediates, wrong ordering, or duplicate certificates causing SSL errors
- Extracting specific certificates -- pull out a single intermediate from a bundle provided by a Certificate Authority
- Certificate chain reordering -- some web servers require a specific order (leaf first, then intermediates); split the chain to rebuild it correctly
- Auditing certificate bundles -- quickly identify what is inside a bundle file without running
openssl x509on each certificate manually - Cross-platform preparation -- extract certificates individually for systems that require separate files (e.g., Java KeyStore imports)
- Incident response -- quickly decompose a chain from a failing server to identify which certificate is causing the problem
How PEM Certificate Chains Work
A PEM bundle is simply multiple PEM certificates concatenated in a single file. Each certificate begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----, with base64-encoded DER data between the markers.
Correct Chain Order
The standard chain order for TLS servers is:
- Leaf certificate -- your server's certificate (the one for your domain)
- Intermediate certificate(s) -- one or more CAs between the leaf and root
- Root certificate (optional) -- the trust anchor; most configurations omit this since clients have root certificates in their trust store
Common Chain Problems the Splitter Detects
| Problem | Symptom | Detection |
|---|---|---|
| Wrong order | Intermediates before leaf | Subject/issuer chain does not follow sequential order |
| Missing intermediate | Browser shows "certificate not trusted" | Gap in issuer-to-subject chain linkage |
| Duplicate certificate | Larger file than expected, wasted bandwidth | Two certificates with identical subject and serial number |
| Self-signed root included | Unnecessary bytes in TLS handshake | Last certificate has matching subject and issuer |
| Extra unrelated certificate | Confusing bundle | Certificate issuer does not chain to any other certificate in bundle |
Server Software Chain Requirements
Different servers handle chain files differently:
- nginx --
ssl_certificateexpects the leaf plus intermediates in one file, leaf first - Apache --
SSLCertificateFilefor the leaf,SSLCertificateChainFilefor intermediates - HAProxy -- single file with leaf + intermediates + private key concatenated
- IIS -- imports PKCS#12 (.pfx) bundles through the GUI; chain installed separately
Debugging Certificate Chains in Practice
The most common chain problem is a missing intermediate certificate. This is tricky to diagnose because desktop browsers often work fine -- they cache intermediates from previous connections and can fetch missing ones via the Authority Information Access (AIA) extension. But non-browser clients like curl, Python's requests library, mobile apps, and IoT devices do not perform AIA fetching. They rely entirely on the server sending a complete chain. If your website works in Chrome but breaks in curl, a missing intermediate is almost certainly the cause.
To diagnose this, retrieve the chain from your server with openssl s_client -connect yourserver.com:443 -showcerts, paste the output into this splitter, and check whether all intermediates are present. Compare the Issuer of each certificate against the Subject of the next one. If there is a gap -- the Issuer of one certificate does not match the Subject of any other certificate in the bundle -- you have a missing intermediate that needs to be added.
Another common problem is including the root certificate in the chain. While this is not technically an error, it wastes bandwidth because clients already have root certificates in their trust stores. Every TLS handshake sends the full chain, so an unnecessary 1-2 KB root certificate adds up across millions of connections. Use the splitter to identify the root (its Subject and Issuer are identical) and remove it from your bundle unless you are deploying to environments with non-standard trust stores.
Frequently Asked Questions
How do I know which certificate is the leaf and which are intermediates? The leaf certificate (end-entity) has a Subject that matches your domain name and its Issuer is a CA, not itself. Intermediate certificates have a Subject that matches the Issuer of the certificate below them in the chain. A root certificate is self-signed -- its Subject and Issuer are identical.
Why does my browser work but other clients fail? Browsers often cache intermediate certificates from previous connections or fetch missing intermediates using the Authority Information Access (AIA) extension. Non-browser clients (curl, mobile apps, API clients) typically do not perform AIA fetching, so they fail if your server does not send the complete chain. Use the splitter to verify your bundle includes all necessary intermediates.
Should I include the root certificate in my bundle? Generally no. Root certificates are pre-installed in client trust stores, so sending them wastes bandwidth (typically 1--2 KB per handshake). However, some specialized environments (embedded devices, internal CAs) may require the root in the chain. The splitter identifies root certificates so you can decide whether to include them.
What if my bundle contains certificates in the wrong order? Split the bundle, identify each certificate's role, then reassemble using the PEM Bundle Merger which automatically determines the correct order. Most modern web servers tolerate out-of-order chains, but some older clients may fail if the leaf is not first.
How do I get the certificate chain from a running server?
Run openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null to retrieve the full chain in PEM format. Copy the output including all BEGIN/END CERTIFICATE blocks and paste it into the splitter.
Related Tools
- PEM Bundle Merger - Reassemble individual certificates into a properly ordered chain
- X.509 Certificate Viewer - Inspect the full details of each extracted certificate
- Certificate Expiry Checker - Check expiry dates for each certificate in the chain
- SAN Extractor - Extract Subject Alternative Names from the leaf certificate
- Convert DER to PEM - Convert binary DER certificates to PEM before bundling