Secure Sockets Layer (SSL) Certificate Converter
Convert PEM, DER, P7B, and PFX certificates in your browser, inspect chain and expiry details, and catch key issues before download.{{ summaryTitle }}
| Field | Value | Copy |
|---|---|---|
| {{ row[0] }} | {{ row[1] }} | |
| Nothing to show yet. | ||
| Check | Status | Detail | Copy |
|---|---|---|---|
| {{ row.area }} | {{ row.status }} | {{ row.detail }} |
| # | Role | Subject | Issuer | Expires | Days | Status | Public key | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.position }} | {{ row.role }} | {{ row.subject }} | {{ row.issuer }} | {{ row.notAfter }} | {{ row.daysRemaining }} | {{ row.status }} | {{ row.keyProfile }} |
{{ artifactPreview }}
Introduction
A certificate file can contain the right certificate and still be rejected by the next system because the wrapper is wrong. Web servers, load balancers, mobile-device managers, Java keystores, Windows certificate stores, and appliances often ask for the same X.509 certificate material in different forms. The job is usually not to change the certificate's identity. It is to put the certificate, chain, and sometimes private key into the container that the importer understands.
X.509 certificates are signed statements about a public key. The certificate names a subject, names the issuer that signed it, carries a serial number, and sets a not-before and not-after validity window. Converting from PEM to DER or from a text chain to a P7B file should preserve those facts. If the subject, issuer, serial number, or public key changes, the work has moved beyond format conversion.
| Format | Usual contents | Common reason to choose it |
|---|---|---|
| PEM | Readable base64 text with BEGIN and END lines | Copy-paste handoffs, Unix-style TLS configuration, and certificate chain review |
| DER | One binary ASN.1 certificate | Devices or tools that expect raw certificate bytes instead of text |
| PKCS#7 / P7B | Certificate-only sets, often used for chains | Sending a leaf certificate with intermediates without exposing a private key |
| PKCS#12 / PFX | Certificates plus one private key, protected by a passphrase | Importing a certificate and key together into a certificate store |
The most common mistake is treating all certificate files as interchangeable. A P7B file is useful when a partner needs only the certificate chain. A PFX file is appropriate when a system must import the certificate with its private key. A DER file is not a full-chain handoff when only one certificate is being exported. A PEM file is easy to inspect, but a combined PEM that includes a private key should be handled like a credential.
Operationally, conversion sits between issuance and deployment. It helps during renewals, server migrations, partner handoffs, appliance imports, and audits of unfamiliar files. It does not decide whether a browser or client should trust the certificate. Hostname matching, trust path validation, revocation, installation location, and private-key match remain separate checks.
That boundary matters most when private keys are involved. A certificate is often public by design, but a private key proves control of the identity. Moving a key into a PFX or combined PEM makes import easier, and it also raises the handling standard for the resulting file.
How to Use This Tool:
Start by confirming what the input contains, then choose the output that the receiving system expects.
- Paste certificate material into Certificate or bundle, or use Browse certificate to load one file. PEM text, base64 DER/P7B/PFX data, and binary certificate files are accepted input paths.
- Choose Info (table/JSON) first when the file is unfamiliar. Check Detected Input, Parsed Type, Subject CN, Issuer CN, Serial (hex), and the validity dates before exporting.
- Open Advanced when the conversion needs a private key, passphrase, PFX friendly name, full-chain choice, private-key inclusion in PEM, strict base64 parsing, or a custom PEM line wrap.
- Use PEM for readable text, DER for one binary certificate, PKCS#7 for certificate-only chain transport, or PKCS#12 when a certificate and private key must be imported together.
- Review Conversion Checks before downloading. A missing key, wrong passphrase, unsupported private-key format, or unrecognized input should be fixed before using the converted file.
- Read Chain Inventory and Validity Horizon when more than one certificate is present. They show the ordered leaf/intermediate set, expiry dates, days remaining, public-key type, and status bands.
- Copy or download the converted artifact only after the summary and result tabs match the handoff you intended. For PFX or combined PEM output, treat the download as credential material.
Interpreting Results:
Certificate Details is the first sanity check. Subject and issuer names catch obvious file mix-ups, serial number helps compare against a CA order or ticket, and the SHA-256 fingerprint gives a compact value for matching the leaf certificate across systems.
Validity Horizon is useful for renewal triage, but the exact Not After timestamp remains the authority. A displayed days-left value can round a certificate expiring later today to 1 day left, so close deadlines should be checked against the timestamp, not only the badge.
- PEM output can include the ordered certificate set and, when enabled, the parsed private key.
- DER output exports only the first ordered certificate, so it is not the right output for a full chain.
- PKCS#7 output carries certificates only. It is a safer fit when the recipient must not receive a private key.
- PKCS#12 output requires both a parsed certificate and a parsed private key. A successful PFX export does not prove the key belongs to the certificate.
- Conversion Checks report parser notes and missing material. Treat a warning there as a stop sign until the source file or options are corrected.
Technical Details:
Certificate conversion is a transformation of encoding and container structure. The certificate's signed content remains the same when conversion succeeds cleanly, while the outer representation changes for a target workflow. That is why a PEM certificate and a DER certificate can describe the same subject, issuer, serial number, public key, and validity period.
The converter identifies PEM blocks, base64-encoded DER-style input, single X.509 certificates, PKCS#7 certificate sets, and PKCS#12/PFX containers. It can also parse supported PEM private keys when a key is pasted separately or found in a supported container. Binary files are read in the browser and converted into a parseable form before the same certificate checks are applied.
Transformation Core:
| Selected output | Material used | Output behavior | Boundary to remember |
|---|---|---|---|
| Info | Parsed certificate and optional key facts | Shows tables, JSON, parser notes, chain rows, and validity chart data without creating a converted file | Inspection is not trust validation. |
| PEM | Leaf certificate, optional chain, optional parsed private key | Writes text blocks with the selected line wrap | Private-key inclusion is off unless explicitly enabled. |
| DER | First ordered certificate only | Writes binary DER bytes and shows a base64 preview for the artifact | Intermediates are not included in this output. |
| PKCS#7 | Leaf certificate plus optional chain | Creates a certificate-only P7B in PEM or DER form | No private key is included. |
| PKCS#12 | Certificate set plus one parsed private key | Creates a binary PFX protected by the passphrase, with an optional friendly name | The export can be built with a blank password, but many import workflows expect one. |
Chain ordering is best-effort. The likely leaf certificate is placed first, then certificates whose subject names match the previous issuer are placed after it. Remaining certificates are kept rather than discarded. This makes exports more useful, but it does not prove that every intermediate is trusted by the destination client.
Formula Core:
The days-left display is calculated from the certificate's not-after timestamp and the current browser time.
Here TnotAfter is the certificate expiry time and Tnow is the time in the current browser. The calculation rounds up, so 2.2 days remaining displays as 3 days left. A certificate that expires later today can still display 1 day left.
| Days-left value | Status | Practical reading |
|---|---|---|
| Less than 0 | Expired | The certificate's not-after time has passed. |
| 0 to 30 | Renew soon | Renewal is close enough to verify the exact timestamp and owner. |
| 31 to 90 | Monitor | The certificate is valid but belongs on a renewal watch list. |
| More than 90 | Valid | The certificate is outside the near-term renewal window shown by the tool. |
| Separate check | Why it matters | What conversion cannot prove |
|---|---|---|
| Private-key match | The service must hold the private key that corresponds to the certificate public key. | That a parsed key belongs to the selected certificate. |
| Hostname identity | TLS clients compare the service name with certificate identifiers. | That the certificate is valid for the intended DNS name or IP address. |
| Trust path | The certificate chain must lead to a trust anchor accepted by the relying client. | That a chain will be accepted by browsers, applications, or appliances. |
| Revocation | A certificate can be revoked before its not-after date. | That the certificate is still acceptable for production TLS. |
Strict base64 parsing changes how copied non-PEM input is handled. With strict parsing off, stray separators and whitespace can be removed before decoding. With strict parsing on, the encoded text must be clean base64, which is better when copied data must fail fast instead of being repaired silently.
Privacy and Safety Notes:
Certificate contents are often safe to share, but private keys and passphrases are secrets. The visible conversion work runs in the browser for the material you provide, yet the safest practice is still to treat every key-bearing output as credential material.
- Do not paste a production private key unless the conversion job truly requires it.
- Use a controlled passphrase for PKCS#12 output when the receiving system allows one.
- The current page URL may include non-default form values. Clear certificate, key, and passphrase fields before copying or sharing a page link.
- Delete temporary downloads and clipboard copies after moving PFX or key-including PEM output to the intended secure store.
- After conversion, verify private-key match, hostname identity, trust path, revocation, and deployment behavior with purpose-built checks.
Worked Examples:
Move a renewed certificate into a Windows import flow. A renewal arrives as a PEM certificate chain, and the receiving console asks for a PFX. Paste the certificate chain, add the matching private key, enter the passphrase, choose PKCS#12 (.pfx, binary), and keep Include full certificate chain on. The expected result is a PFX artifact plus Conversion Checks showing the certificate and key are both present.
Send a partner a certificate-only chain. A partner asks for a P7B and must not receive the private key. Paste the PEM chain, choose PKCS#7 (.p7b, DER) or PKCS#7 (.p7b, PEM) as requested, and leave the private-key field blank. The Conversion Artifact contains certificates only.
Export one certificate for a device. A hardware appliance accepts one DER certificate. Load the source file, confirm the intended leaf appears first in Chain Inventory, then choose DER (.der). If the chain contains intermediates, the DER output still contains only the first ordered certificate.
Recover from a failed PFX parse. A base64 PFX paste produces a parser note about PKCS#12 parsing. Enter the passphrase in Advanced and try again. If Conversion Checks still shows a parser note, the source may be damaged, password-protected with a different passphrase, or not a PFX/P12 file.
FAQ:
Is an SSL certificate different from a TLS certificate?
The phrase SSL certificate is still common, but the certificate material being converted is X.509 certificate material used by modern TLS deployments.
Can a P7B file include my private key?
No. The PKCS#7 output here is certificate-only. Use PKCS#12 or PEM with private-key inclusion when a key must travel with the certificate.
Why does DER output drop the rest of my chain?
DER output is a single-certificate export in this converter. Use PEM or PKCS#7 when intermediates need to stay with the leaf certificate.
Does a successful PFX export prove the key matches the certificate?
No. It proves the certificate and private key were parsed and packaged together. Verify the key match before deploying the certificate.
Why does the days-left value differ from my monitoring system?
The value is rounded up from the current browser time to the certificate's not-after time. Time zone display, polling time, and exact timestamp handling can make another system show a slightly different count.
What should I do when the tool says a passphrase is required?
Enter the passphrase in Advanced when opening an encrypted private key or protected PFX/P12 file. If the note remains after retrying, the passphrase or file format is probably wrong.
Glossary:
- X.509 certificate
- A signed certificate structure that binds a subject identity and public key to an issuer and validity period.
- PEM
- A text envelope around base64-encoded certificate or key material, marked by BEGIN and END lines.
- DER
- A binary ASN.1 encoding commonly used for one certificate at a time.
- PKCS#7 / P7B
- A certificate-only container often used to move a leaf certificate with intermediates.
- PKCS#12 / PFX
- A container that can carry certificates and a private key protected by a passphrase.
- Leaf certificate
- The end-entity certificate for the service, device, or identity, before intermediate and root certificates.
- Trust path
- The certificate chain that must lead from the leaf certificate to a trusted root accepted by the client.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008.
- RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures, IETF, April 2015.
- RFC 2315: PKCS #7: Cryptographic Message Syntax Version 1.5, IETF, March 1998.
- RFC 7292: PKCS #12: Personal Information Exchange Syntax v1.1, IETF, July 2014.
- RFC 9525: Service Identity in TLS, IETF, November 2023.