Import a certificate and its key from a PEM or PFX file and export exactly the bundle your server needs: a fullchain (leaf plus intermediates), a chain-only file, or a combined cert + key file. Use it when you are moving a site to a new server, splitting a PFX into its parts, or rebuilding a chain that came back without its intermediates. To change the format itself (PEM, DER, P7B) rather than move files between servers, use the SSL Converter instead.
How to Use
1Paste your certificate and optionally the private key.
2Select the output format (PEM, DER, PKCS#12, PKCS#7).
Certificates exist in several encodings because different systems expect different ones. This page converts between them, and says so plainly when it cannot.
1Accept PEM or DER input and identify which you supplied from the content rather than the filename, so a mislabelled file still converts correctly.
2Parse and re-encode the certificates into the requested output format. Because both directions go through a canonical form, the result is a faithful conversion of the same certificates rather than a reinterpretation.
3Report failures as failures, naming what could not be parsed. Conversion that silently produces an empty or partial result is worse than an error, because you find out at deployment rather than here.
Conversion is re-encoding, not reissuing. The certificates are unchanged and carry the same validity, issuer and trust properties as before — only the byte-level representation differs.
Tips & Best Practices
•Keep PFX passwords secure — they protect your private key
•When importing, ensure all intermediate certificates are included
•Use PEM format for web servers, PFX/P12 for Windows systems
Frequently Asked Questions
They are the same certificate in two encodings. DER is the binary form the certificate authority actually issued, and it is what certificate stores and Java key stores hold internally. PEM is that binary rendered as base64 text between BEGIN and END markers, which makes it roughly a third larger but readable, pasteable and storable in a configuration file. Conversion between them changes nothing about the certificate: the fingerprint is identical, which is the quickest way to prove a conversion was lossless.
PKCS#12 is a container that holds a certificate, its private key and the intermediate certificates that go with it in one password-protected file. It exists because those three things are usually needed together and distributing them separately is awkward, which is why Windows and Java tooling has standardised on it. Note that the private key is inside, so a PFX file is secret material: treat it accordingly, and use the PFX to PEM tool when you need the pieces separated.
Yes, PKCS#12 is defined around password-based encryption of the private key, and most tooling will not produce one without a password. Choose a real one, because an empty or trivial password reduces the file to a plain private key sitting on disk. The trade-off is that anything consuming the file has to supply the password, so record where it is stored rather than where it is written, and prefer leaving the export unencrypted when you have just generated a key yourself and the file is still on your own machine.
No. Conversion is re-encoding: the same certificate expressed in a different byte-level representation. Subject, issuer, validity, serial and signature all remain identical, and the trust properties are unchanged. That is why a converted certificate validates exactly as the original did — and why conversion cannot repair an expired or wrong-name certificate, since neither is a property of the encoding.
PEM for almost everything on the web: nginx, Apache, HAProxy, load balancers and most container tooling all read text files. DER is for Windows services and some appliances, and for contexts where a binary file is expected. PKCS#12 is for Windows certificate stores and for anything needing the private key bundled with the certificate — which is a different operation entirely, since a private key must be involved.
Usually the file is not one certificate. A PEM chain with several certificates separated by blank lines converts as a bundle and produces multiple outputs, which some tools reject; and a file that is actually a private key or a CSR is correctly refused as not a certificate. The error message names what was found, so read it before assuming the file is corrupt.
Rarely, for most people. PEM is close to universal on the web and the conversion pages here exist for the specific cases where a system insists on something else — a Windows service, an appliance, a certificate embedded in a binary. If you are not sure what your target expects, its documentation will say, and choosing PEM is the safe default.
That is a bundling operation rather than a conversion: concatenating the leaf and its intermediates into one PEM file. The order matters — leaf first, then intermediates in chain order — and the chain builder on this site produces the correct sequence from certificates you paste. Getting the order wrong produces an incomplete chain error that looks like a trust problem.
