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

  1. Paste your PEM bundle containing multiple -----BEGIN CERTIFICATE----- blocks
  2. The tool identifies and separates each certificate in the bundle
  3. Review the parsed subject and issuer for each extracted certificate
  4. 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:

#TypeSubjectIssuer
1End-entityCN=www.example.comCN=R3, O=Let's Encrypt
2IntermediateCN=R3, O=Let's EncryptCN=ISRG Root X1
3RootCN=ISRG Root X1CN=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 x509 on 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:

  1. Leaf certificate -- your server's certificate (the one for your domain)
  2. Intermediate certificate(s) -- one or more CAs between the leaf and root
  3. 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

ProblemSymptomDetection
Wrong orderIntermediates before leafSubject/issuer chain does not follow sequential order
Missing intermediateBrowser shows "certificate not trusted"Gap in issuer-to-subject chain linkage
Duplicate certificateLarger file than expected, wasted bandwidthTwo certificates with identical subject and serial number
Self-signed root includedUnnecessary bytes in TLS handshakeLast certificate has matching subject and issuer
Extra unrelated certificateConfusing bundleCertificate issuer does not chain to any other certificate in bundle

Server Software Chain Requirements

Different servers handle chain files differently:

  • nginx -- ssl_certificate expects the leaf plus intermediates in one file, leaf first
  • Apache -- SSLCertificateFile for the leaf, SSLCertificateChainFile for 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

IPparse•Free Network & Subnet Calculator Tools

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected