How to Create .pem File for SSL Certificate Installation

What is a PEM File?

A PEM file is a text-based format for storing and transmitting cryptographic keys, certificates, and certificate chains. Rather than being a unique file type, PEM is a container format that uses Base64 encoding to represent binary data in a readable ASCII format. Each PEM file contains one or more blocks surrounded by recognizable boundary markers like:

or

PEM stands for Privacy Enhanced Mail, a protocol developed to secure emails in the early days of the internet. While its original use case faded, the PEM format itself became widely adopted for SSL/TLS certificates and is now the standard for web servers, load balancers, reverse proxies, DNS providers, DevOps platforms, and certificate authorities.

One of the main reasons for PEM’s popularity is its flexibility:

• A single PEM file can contain multiple certificates (e.g., server + intermediate chain).

• PEM can hold both a certificate and its associated private key.

• It’s human-readable and can be opened and edited in a text editor.

• It works seamlessly across popular platforms like Apache, NGINX, HAProxy, AWS ACM, Traefik, Kubernetes, and OpenSSL.

Compare that with other formats like DER (binary), PFX/P12 (encrypted archive), or JKS (Java keystore format), and it’s clear why PEM is often the required or preferred format in modern deployments.

In short: if you’re working with SSL certificates on Linux servers, cloud infrastructure, or containers — knowing how to construct and manipulate PEM files is essential.

Understanding SSL File Formats (CRT, CER, DER, PEM, PFX, etc.)

When dealing with SSL/TLS certificates, it’s common to encounter a variety of file formats, which can often lead to confusion—especially when you’re preparing a certificate for installation or migrating between different platforms. While all SSL certificates follow the X.509 standard, the way they’re stored and encoded varies depending on the operating system, server type, or certificate authority (CA). Understanding these formats is crucial for creating the correct .pem file for your setup.

Here’s a breakdown of the most common certificate formats and how they relate to each other:

PEM (.pem, .crt, .cer, .key)

PEM is a Base64-encoded, textual format used across most Unix/Linux-based systems. It’s the most common format for SSL certificates and private keys, especially on platforms like NGINX, Apache, HAProxy, and Kubernetes.

PEM files usually contain:

• Public certificate: -----BEGIN CERTIFICATE-----

• Private key: -----BEGIN PRIVATE KEY-----

• Certificate chain: intermediate or root CA certificates

File extensions such as .pem, .crt, .cer, and .key are often PEM-encoded files—the content matters more than the extension.

DER (.der)

DER is a binary-encoded form of a certificate. It’s commonly used with Java platforms or Windows environments. A .cer file may be DER or PEM, so you should open it in a text editor to know for sure.

• DER files will look like binary (non-readable) when opened.

• Can be converted to PEM using OpenSSL.

CRT and CER (.crt, .cer)

These are often PEM or DER encoded certificates. While .crt is more common in Linux servers and .cer on Windows, the extension doesn’t inherently define the encoding.

• To verify the encoding: open the file in a text editor. If it contains BEGIN CERTIFICATE, it’s PEM.

• If it’s binary (non-readable), it’s likely DER.

PFX/P12 (.pfx, .p12)

PFX (also called PKCS#12) is a binary archive format that can bundle a certificate, private key, and full certificate chain in one file. It’s commonly used on Windows/IIS servers, Microsoft Azure, and some VPN appliances.

• Requires a password to open or extract contents

• Often needs to be converted into PEM format for Linux-based servers (e.g., NGINX, Apache)

JKS (.jks)

Java Keystore (JKS) is used specifically by Java applications like Tomcat, WebSphere, or certain microservice deployments. It stores certs and keys securely but isn’t directly compatible with PEM without conversion.

Key Takeaways Before Creating a PEM File:

1. Always inspect certificate contents before converting. Look for base64-encoded text vs binary.

2. Know what your platform expects. Some require a single combined PEM, others need separate .pem files for the private key, server certificate, and full chain.

3. OpenSSL can convert between almost any certificate format. If you can’t install a .crt or .pfx directly, convert it to a PEM.

Next, we’ll cover when and why you need specific PEM file types, depending on whether you’re using NGINX, Apache, Kubernetes, AWS ACM, or HAProxy.

When Do You Need PEM Files?

PEM files are required in many modern SSL/TLS deployments because they’re compatible with a wide range of tools, servers, and cloud platforms. As a result, the ability to correctly format, combine, and deploy PEM files has become an essential skill for system administrators, DevOps engineers, and cloud architects.

Depending on the platform or service you’re using, you may need to prepare one or more PEM files containing:

• Just the server certificate

• The server certificate plus intermediate certificates (known as the full chain)

• The server certificate, intermediate certificate(s), and private key — all in one file

Below are some of the most common platforms and scenarios where PEM files are required, along with what type of PEM file they expect.

1. NGINX

NGINX requires two separate PEM files for SSL configuration:

• ssl_certificate: Contains the server certificate followed by intermediate certificates (i.e., the full chain). This is often called fullchain.pem

• ssl_certificate_key: Contains the private key in PEM format, typically called privkey.pem

These files are referenced in the server’s SSL block, for example:

If either file is missing or formatted incorrectly, NGINX will fail to start, or browsers will display a certificate validation error.

2. Apache

Like NGINX, Apache can accept certificates in PEM format, but its configuration is slightly more flexible. Apache allows:

• Separate files for the server certificate, private key, and certificate chain

• Or a combined PEM for the certificate and chain

Example configuration in Apache:

Apache won’t start properly unless the certificate and key match, and the full certificate chain is provided.

3. HAProxy

HAProxy expects a single PEM file that includes everything the SSL stack needs:

• Certificate

• Private key

• Intermediate certificates

These must be concatenated in the correct order into one .pem file. This file is then passed to the crt parameter in HAProxy’s config:

If the private key or chain is missing from the PEM, HAProxy will either throw an error or break the SSL handshake for clients.

4. AWS Certificate Manager (ACM)

AWS ACM accepts imported certificates in PEM format only, and each file must be structured correctly:

• Certificate body (-----BEGIN CERTIFICATE-----)

• Private key (-----BEGIN PRIVATE KEY-----)

• Certificate chain (if applicable)

AWS rejects encrypted private keys and improperly formatted PEM files. This is common when converting from PFX or unverified formats.

5. Kubernetes (TLS Secrets)

When you create a TLS secret in Kubernetes, you must provide two PEM-formatted files:

• tls.crt — contains the certificate (optionally with chain)

• tls.key — contains the private key

Example to create a TLS secret:

Incorrect formatting in either file will cause ingress controllers like NGINX Ingress or Traefik to throw errors.

6. Load Balancers, Mail Servers, DevOps Tools

Many other services also require PEM files, including:

• Cloudflare Origin Certificates

• Postfix and Dovecot (for SMTP/IMAP TLS)

• Docker Swarm and Traefik reverse proxies

• Envoy, OpenVPN, LDAP, and MQTT brokers

Key Insight

The core of PEM usage revolves around server compatibility and chain trust. Whether you’re creating a single .pem for HAProxy or building a fullchain.pem for NGINX, the goal is always the same: provide the server with the exact combination of certificate components it needs to complete a secure handshake with clients.

Creating PEM Files from Existing Certificates

Creating a PEM file for SSL certificate installation typically involves organizing or converting existing certificate materials into the correct format and structure expected by your server or platform. These materials often include:

• A server certificate (e.g., yourdomain.crt or certificate.cer)

• A private key (e.g., yourdomain.key)

• One or more intermediate certificates, provided by the Certificate Authority (CA)

Depending on your environment, you may need to combine these into one .pem file, split them into multiple .pem files, or convert them from other formats such as .pfx or .der.

Below are detailed, step-by-step instructions for preparing PEM files from the most common certificate components.

1. Creating PEM Files from .crt and .key Files

When you receive a certificate from a trusted CA, you’ll usually get multiple files — such as a server certificate (.crt) and a matching private key (.key). To deploy this certificate in PEM format, you may need to:

• Keep them separate (e.g., for NGINX or Apache)

• Combine them into a single PEM file (e.g., for HAProxy)

First, check whether your .crt file is already in PEM format by opening it in a text editor. If it contains lines like:

then it’s already PEM-encoded. If not, you’ll need to convert it.

2. Creating fullchain.pem (Server + Intermediate Certificates)

Many servers (such as NGINX) require a fullchain.pem file that includes both the server’s certificate and one or more intermediate certificates. This helps the browser build a complete trust chain.

To create fullchain.pem, do the following:

1. Open your server certificate (cert.crt) in a text editor.

2. Open your intermediate certificate(s), often provided as intermediate.crt or ca-bundle.crt.

3. Create a new file called fullchain.pem.

4. Paste the server certificate first, then the intermediate certificate(s), one after the other.

Example:

Save and close the file. You now have a fullchain.pem.

3. Creating privkey.pem from a Private Key

If your private key is already in PEM format (contains -----BEGIN PRIVATE KEY-----), you can simply rename it to privkey.pem.

If it’s encrypted or in a different format, you’ll need to decrypt or convert it using OpenSSL:

To remove a passphrase from a private key:

You now have a decrypted privkey.pem suitable for server use.

4. Verifying a Certificate and Private Key Match

Before combining or deploying PEM files, it’s critical to ensure that the certificate and key match.

You can do this by comparing their modulus:

If the hash output matches, they correspond.

5. Combining Certificate and Key in a Single PEM

Some platforms (e.g., HAProxy, Postfix, some load balancers) require the certificate and private key to be combined into a single .pem file.

To create a combined .pem:

To also include the intermediate chain:

Note the order:

1. Certificate

2. Intermediate(s)

3. Private key

This structure is essential for compatibility.

6. Converting from Other Formats (Overview)

Many real-world scenarios involve converting from .pfx, .p12, .der, or .cer to .pem. This is common when migrating certificates between Windows IIS, Azure, and Linux servers.

For instance, to convert .pfx to .pem:

We’ll cover this in more detail in the next section: “Converting PFX/P12 to PEM with OpenSSL.”

Summary

By preparing or combining .crt, .cer, .key, and intermediate certificates into .pem format, you’re ensuring compatibility with a wide range of systems that use PEM-based certificate handling for HTTPS, reverse proxies, load balancers, and more. The exact PEM structure depends on your platform, but the content — certificates and private keys — are always the same.

Creating PEM Files for Specific Platforms

Once you’ve prepared your certificate and private key in PEM format, the next challenge is assembling and formatting them correctly for your specific platform or server environment. Different platforms require different file structures, naming conventions, or ordering of certificate materials. Misplacing even a single line in these files can result in SSL handshake errors, chain validation failures, or service downtime.

Below, we’ll walk through how to create and deploy PEM files for several common platforms including NGINX, Apache, HAProxy, AWS ACM, and Kubernetes. Each section includes real configuration examples and the exact PEM file format expected.

1. Creating PEM Files for NGINX

NGINX uses two separate PEM files for SSL configuration:

1. ssl_certificate
   This must contain the server certificate and the intermediate certificates — combined in the correct chain order. This file is typically named fullchain.pem.

2. ssl_certificate_key
   This must contain the private key in PEM format — often named privkey.pem.

Example folder layout:

NGINX configuration:

Important notes:

• The fullchain.pem file must include your certificate first, followed by the required intermediate certificates.

• If the intermediate certificate is missing or out of order, browsers may show errors such as NET::ERR_CERT_AUTHORITY_INVALID or unable to get local issuer certificate.

Once files are in place, restart NGINX:

To verify chain structure:

2. Creating a Single .pem File for HAProxy

Unlike NGINX, HAProxy requires a single PEM file that contains the following content in this exact order:

1. Server certificate

2. Intermediate certificate(s)

3. Private key

This single PEM file is referenced by the crt directive in HAProxy’s configuration.

Steps to build the .pem file:

HAProxy configuration example:

Notes:

• If another tool (like Certbot) generated your certificate files, verify they’re in PEM format before concatenating.

• If the PEM is misordered or missing a key, HAProxy will fail to start or terminate SSL with handshake errors.

Restart HAProxy when finished:

3. Preparing PEM Files for AWS Certificate Manager (ACM)

AWS ACM requires certificates to be imported in three separate blocks — but all blocks must be in PEM format. You cannot upload encrypted private keys or DER-based certificate files.

To import a certificate into AWS ACM, you must have:

1. Certificate body (your server certificate)

2. Private key (unencrypted)

3. Certificate chain (intermediate CA certificates)

How to upload via AWS CLI:

Key rules:

• The private key must not be password protected.

• The chain file should not include the root CA.

4. Creating TLS Secrets in Kubernetes (kubectl)

Kubernetes uses TLS secrets to supply SSL certificates to pods, ingresses, and other resources. These secrets require two PEM-formatted files:

• tls.crt — contains the certificate (can optionally include the chain)

• tls.key — contains the private key

Step 1: Prepare the PEM files

Step 2: Create the K8s secret

Sample Ingress configuration:

Ingress controllers like NGINX Ingress or Traefik will automatically use the PEM files stored in your Kubernetes secret to terminate TLS at the load balancer or ingress layer.

Additional Platforms That Use PEM Files