Certificate PEM Splitter
Subject
CN=...
Valid to
2027-03-26
How it works
PEM (Privacy Enhanced Mail) is the base64+header format used to encode X.509 certificates, private keys, certificate signing requests (CSRs), and certificate chains. A PEM file often contains multiple concatenated certificates — the end-entity certificate followed by intermediate CA certificates. This tool splits a multi-certificate PEM bundle into individual PEM blocks for inspection, import, or format conversion.
**PEM format structure** Each PEM block begins with -----BEGIN [TYPE]----- and ends with -----END [TYPE]-----. Types include: CERTIFICATE, PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY, CERTIFICATE REQUEST, PUBLIC KEY. Between the headers: base64-encoded DER (Distinguished Encoding Rules) binary data, with 64-character line wrapping.
**Certificate chain order** TLS certificate bundles should be ordered: end-entity certificate first, then intermediate CA(s) in order, then optionally the root CA (browsers and OS typically have root CAs in their trust stores and do not require the root in the chain). Incorrect chain order causes "certificate chain incomplete" TLS errors. nginx uses ssl_certificate for the chain file (end-entity + intermediates); ssl_certificate_key for the private key.
**Common operations after splitting** Decode individual certificates: openssl x509 -in cert.pem -text -noout. Convert PEM to DER: openssl x509 -in cert.pem -outform DER -out cert.der. Extract public key: openssl x509 -pubkey -noout -in cert.pem. Verify chain: openssl verify -CAfile chain.pem cert.pem.
Frequently Asked Questions
- Run: openssl verify -CAfile root-chain.pem -untrusted intermediates.pem server.pem. Or check the full chain: openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text. The correct order is: end-entity certificate first (the cert with your domain in CN/SAN), then intermediate CA certificates in signing order (each cert signed by the next one up), then optionally the root CA. nginx and Apache serve the chain file in this order. Incorrect order causes 'certificate chain incomplete' errors in some clients.
- Certificate (cert.pem): just the end-entity certificate for your domain — one PEM block. Chain file (chain.pem): the intermediate CA certificates only — usually one or two PEM blocks. Bundle/fullchain (fullchain.pem): end-entity certificate + all intermediate CAs concatenated — what nginx's ssl_certificate directive expects. CA bundle: collection of trusted root CA certificates — used to verify other certs (what curl's --cacert expects). Let's Encrypt's certbot creates fullchain.pem (end-entity + intermediates) and cert.pem (end-entity only) separately.
- Look for the header lines: -----BEGIN CERTIFICATE----- contains an X.509 certificate. -----BEGIN PRIVATE KEY----- contains a PKCS#8 private key. -----BEGIN RSA PRIVATE KEY----- contains a PKCS#1 RSA private key (legacy format). -----BEGIN CERTIFICATE REQUEST----- contains a CSR. Multiple -----BEGIN CERTIFICATE----- blocks indicate a certificate chain or bundle. Count the BEGIN/END pairs to know how many certificates are in the file. This tool splits each block and decodes the content without requiring OpenSSL.
- Current maximum validity: 398 days (13 months), enforced by Apple, Chrome, and Mozilla since September 2020. Previously certificates were valid up to 3 years. The industry is moving toward 90-day maximum (Google's announced target for Chrome root program, effective 2024). Rationale: shorter lifetimes limit exposure from compromised keys (if a private key is stolen, the window of attacker use is bounded by certificate validity). They also force organizations to maintain working certificate renewal automation — preventing the category of outages caused by forgotten long-lived certificates.