LiveChat 
Support 
How to Convert a .txt to a .cer Certificate File (PEM, DER, and the Extension Confusion Explained)
You received your SSL certificate as a block of text, possibly in an email or a `.txt` file, and the platform you need to install it on is asking for a `.cer` file. So you go looking for a “txt to cer converter,” expecting some complex transformation. Here is the reassuring truth: in most cases, there is nothing to convert at all. A `.cer` file is frequently just the same certificate text saved under a different name.
This guide explains what a `.cer` file actually is, why the `.txt` confusion happens, the real difference between PEM and DER encoding, and exactly when you need a tool like `openssl` versus when a simple rename gets the job done.
Key Takeaways
• A `.cer` file is just a certificate file; it can hold either PEM-encoded text or DER-encoded binary data.
• “Converting” a `.txt` to `.cer` is usually just saving the same PEM text with a `.cer` extension — no real conversion needed.
• The extensions `.crt`, `.cer`, and `.pem` very often contain identical PEM (Base64) text.
• You only need `openssl` when you must change the encoding itself (PEM to DER, or DER to PEM).
• Always confirm the `—–BEGIN CERTIFICATE—–` and `—–END CERTIFICATE—–` markers are intact for PEM files.
Why does a certificate arrive as a .txt file?
When a Certificate Authority issues your SSL certificate, it commonly delivers it as PEM-encoded text. PEM (Privacy-Enhanced Mail) is a human-readable format: a header line, a long block of Base64 characters, and a footer line. Because it is plain text, it travels easily through email bodies, control panel text boxes, and copy-paste workflows.
Many people then paste that text into a basic text editor and save it. The editor defaults to a `.txt` extension. Now you have a perfectly valid certificate sitting inside a file that *looks* like a generic document. A typical PEM certificate looks like this:
“`
—–BEGIN CERTIFICATE—– MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD … (many more lines of Base64) …
—–END CERTIFICATE—– “`
The content is correct. Only the filename and extension are “wrong” for the system you are trying to feed it into.
What exactly is a .cer file?
A `.cer` file is simply a file that contains an X.509 certificate. The extension tells you almost nothing about the *encoding* inside. This is the single biggest source of confusion.
A `.cer` file can contain:
- PEM-encoded text — the same Base64 block with `BEGIN`/`END` markers you might have in a `.txt`.
- DER-encoded binary — a compact, non-human-readable byte stream.
On Windows, the `.cer` extension is strongly associated with certificates and double-clicking one opens the Certificate viewer. But Windows happily handles both PEM and DER content inside a `.cer` file. This is why “convert txt to cer” rarely means a true format change — it usually means “give this certificate the name and extension my system expects.”
What is the difference between PEM and DER encoding?
This is the distinction that actually matters. Forget the extensions for a moment and focus on the two ways certificate data is encoded.
- PEM is Base64-encoded ASCII text wrapped in `—–BEGIN CERTIFICATE—–` and `—–END CERTIFICATE—–` markers. You can open it in any text editor and read the structure. It can hold multiple certificates stacked together (useful for certificate chains).
- DER is the raw binary form of the same certificate. It contains no markers and is not human-readable. Open it in a text editor and you will see scrambled symbols.
The relationship between them is direct: PEM is essentially DER that has been Base64-encoded and given text headers. Converting between the two does not change the certificate; it only changes how those identical bytes are represented.
Common certificate extensions at a glance
The table below maps the extensions you will encounter to what they usually contain. Note the heavy overlap — this overlap is exactly why naming feels chaotic.
| Format / Extension | Encoding | Human-readable? | Typically contains | Common use |
|---|---|---|---|---|
| `.pem`, `.crt`, `.cer` | PEM (Base64 text) | Yes | One certificate (or a chain) | Apache, Nginx, most Linux servers, email delivery |
| `.cer`, `.der` | DER (binary) | No | A single certificate | Windows, Java keystores, some appliances |
| `.pfx`, `.p12` | PKCS#12 (binary bundle) | No | Certificate plus private key (+ chain) | Windows / IIS import, full identity export |
Two things to take from this table. First, `.crt`, `.cer`, and `.pem` are *often the same PEM text* — interchangeable by rename. Second, `.cer` is ambiguous: it can be PEM or DER, so you must inspect the file to know which you have.
How do you actually convert a .txt to a .cer file?
There are two real scenarios. Identify yours before touching any command.
Scenario 1: Your .txt already contains PEM text (the common case)
If you open the file and see `—–BEGIN CERTIFICATE—–`, your certificate is already PEM-encoded. The system asking for a `.cer` almost certainly accepts PEM. In this case, “conversion” is just a rename or re-save.
On Linux or macOS:
“`bash cp certificate.txt certificate.cer “`
On Windows PowerShell:
“`powershell Copy-Item certificate.txt certificate.cer “`
That is the entire operation. The bytes are unchanged; only the extension differs. Before handing it off, verify the markers are intact — no leading spaces, no missing characters, and a clean `—–END CERTIFICATE—–` line at the bottom.
Scenario 2: The target system needs DER-encoded binary
Some platforms (certain Windows tools, Java environments, or hardware appliances) specifically require a DER-encoded `.cer`. Here you must genuinely transcode from PEM to DER, and this is where `openssl` earns its place.
Convert PEM text to a DER-encoded `.cer`:
“`bash openssl x509 -inform PEM -outform DER -in certificate.pem -out certificate.cer “`
If your source is the `.txt` file, just point at it directly:
“`bash openssl x509 -inform PEM -outform DER -in certificate.txt -out certificate.cer “`
Need to go the other way — from a DER `.cer` back to readable PEM text?
“`bash openssl x509 -inform DER -outform PEM -in certificate.cer -out certificate.pem “`
The flags read plainly: `-inform` is the input format, `-outform` is the output format. Get those right and the conversion is deterministic.
How do you verify a .cer certificate is correct?
Never assume a renamed or converted file is valid — confirm it. `openssl` can print the human-readable details of a certificate regardless of whether it started as PEM or DER.
For a PEM-encoded file:
“`bash openssl x509 -in certificate.cer -text -noout “`
For a DER-encoded file, tell openssl the input format:
“`bash openssl x509 -inform DER -in certificate.cer -text -noout “`
A healthy output shows the Subject, Issuer, validity dates (`Not Before` / `Not After`), and the public key details. The `-noout` flag suppresses the re-encoded certificate so you only see the readable summary.
If you simply want to confirm a file is PEM text, check for the markers. If the command above errors out on a PEM attempt, the file is probably DER (or corrupted) — switch to the `-inform DER` variant to confirm.
Common pitfalls to check:
- Broken markers — a truncated `BEGIN`/`END` line silently invalidates PEM. Copy-paste from email is a frequent culprit.
- Hidden whitespace or Windows line endings — stray `\r\n` or trailing spaces can trip strict parsers.
- Wrong file entirely — make sure you are not converting the private key or a CSR by mistake; those have different `BEGIN` headers.
- Encoding mismatch — handing a PEM file to a system that demands DER (or vice versa) produces confusing import errors that look like “invalid certificate.”
Skip the format wrangling: managed SSL with DarazHost
If juggling PEM, DER, `.cer`, and `.pfx` extensions feels like more plumbing than it should be, that is precisely the friction DarazHost is built to remove. Our hosting plans include free SSL certificates that are installed and managed for you — issuance, format handling, and renewal happen behind the scenes, so you never have to rename a file or run a conversion command just to secure a site.
For teams that *want* hands-on control, our VPS hosting gives you full root access and a complete `openssl` toolchain, so you can generate, convert, inspect, and deploy certificates manually whenever your workflow demands it. And whichever path you choose, our 24/7 support team can help troubleshoot certificate formats, chain issues, and installation problems directly. You get the choice between fully managed convenience and full manual control — without being locked into either.
Frequently asked questions
Is a .cer file the same as a .crt file? Very often, yes. Both can contain PEM-encoded certificate text and are then interchangeable by rename. The difference is convention: `.crt` is common on Linux/Unix servers, while `.cer` is favored on Windows. However, a `.cer` may alternatively hold DER binary, so always check the contents rather than trusting the extension.
Do I need openssl to convert txt to cer? Usually not. If your `.txt` already contains `—–BEGIN CERTIFICATE—–`, you only need to rename or re-save it as `.cer`. You need `openssl` solely when the target system requires DER-encoded binary and your source is PEM text (or vice versa).
How do I know if my .cer is PEM or DER? Open it in a text editor. If you see readable `—–BEGIN CERTIFICATE—–` headers and Base64 lines, it is PEM. If you see unreadable binary symbols, it is DER. You can also confirm with `openssl x509 -in file.cer -text -noout` for PEM and the `-inform DER` variant for DER.
Can I convert a .cer back to plain readable text? Yes. If it is DER-encoded, run `openssl x509 -inform DER -outform PEM -in certificate.cer -out certificate.pem` to produce readable PEM text. If it is already PEM, it *is* the readable text — just open it in any editor.
Why does my certificate import fail even after converting? The most frequent causes are an encoding mismatch (PEM supplied where DER is required), broken BEGIN/END markers from copy-paste, or supplying the wrong file (a private key or CSR instead of the certificate). Verify with `openssl x509 … -text -noout` and confirm you are working with the certificate itself, not an associated key or request.
Conclusion
The “txt to cer” problem is far less intimidating once you separate extension from encoding. In the common case, your `.txt` already holds PEM text, and converting to `.cer` is just a rename. Only when a system demands DER binary do you reach for `openssl x509 -inform PEM -outform DER`. Inspect first, confirm the `BEGIN`/`END` markers, verify with `openssl x509 -text -noout`, and you will sidestep the import errors that catch most people out. And if you would rather not think about certificate formats at all, managed SSL handles the whole lifecycle for you.
