Create PEM certificates
A PEM certificate is not a separate trust level like DV or OV, but a very common file format used to store certificates, private keys, certificate requests, and full certificate chains. In practice it is a text-based format with blocks that begin and end with labels such as CERTIFICATE, PRIVATE KEY, or CERTIFICATE REQUEST. That is exactly why PEM is so common in Linux environments, Apache, NGINX, HAProxy, API clients, load balancers, and automation scripts. When an administrator needs to enable HTTPS on a site, generate a CSR for a certificate authority, or convert a PFX file into something a web server understands, the work often ends with PEM files.
This matters in both small and large environments. A public site or online store using SSL Certificates needs the certificate, intermediate chain, and private key arranged correctly. On Hosting, some of this may be automated, but on Virtual Servers the administrator usually manages the files, permissions, and OpenSSL commands directly. That is why understanding PEM is not just background theory but a practical operational skill.
The first thing to separate clearly is the four most common pieces. A private key is the secret key that must stay under your control and must never be published. A CSR, or Certificate Signing Request, is the request you generate and send to a certificate authority or use in automated issuance. A CRT or CERTIFICATE file is the certificate you receive in return. A chain file contains intermediate certificates that help clients validate the server certificate properly. All of these can exist in PEM form, which is why people often say “create a PEM certificate” when they really mean the whole certificate set rather than one single file.
The safest and most common workflow is straightforward: first generate a private key, then generate a CSR, then receive the certificate from the issuer, and finally combine or convert files as needed into a PEM-based layout the server can use. Once that sequence makes sense, most certificate handling becomes much easier. Problems usually begin when files are mixed up, the wrong private key is used, or the administrator forgets that many servers need not only the leaf certificate but also the intermediate chain.
# 1. Generate a private key openssl genrsa -out private.key 2048 # 2. Generate a CSR openssl req -new -key private.key -out request.csr
When creating a CSR, OpenSSL asks for information such as country, organization, and Common Name. The hostname information is critical because it determines which domain names the certificate will actually cover. If the service is meant for example.com and www.example.com, that data should be entered carefully. In modern deployments, Subject Alternative Name values matter the most, because current certificate validation relies on SAN rather than on Common Name alone.
# CSR example with subject data openssl req -new -key private.key -out request.csr -subj "/C=LV/ST=Riga/L=Riga/O=Company/CN=example.com"
After the certificate authority issues your certificate, you usually receive one or more files: the server certificate itself, one or more intermediate certificates, and sometimes guidance about how to build the chain. In Linux environments it is very common to prepare a fullchain file where the server certificate comes first and the intermediate certificates follow it. This matters because without the correct chain, some clients or services may warn about incomplete trust even if the certificate appears to work in your own browser.
# Build a full chain file cat server.crt intermediate.crt > fullchain.pem
Another very common task is converting a PFX or P12 bundle into PEM files. This typically happens when a certificate was exported from Windows, IIS, or a device management tool and then needs to be used on NGINX, Apache, HAProxy, or in another Linux-oriented service. A PFX file may contain the certificate, the private key, and sometimes the chain as well. OpenSSL can extract each piece, but you need to keep the results organized and protect the private key properly.
# Extract the certificate from a PFX file openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out server.crt # Extract the private key openssl pkcs12 -in certificate.pfx -nocerts -nodes -out private.key # Extract intermediate certificates openssl pkcs12 -in certificate.pfx -cacerts -nokeys -out chain.crt
Because PEM is text-based, it is easy to open and inspect with a text editor. That is convenient, but it also creates room for mistakes. Administrators sometimes copy certificate content with broken line endings, extra spaces, or incomplete BEGIN and END markers. The private key in particular must be stored carefully. On Linux, it is normal to keep it outside publicly accessible web directories and assign restrictive file permissions so that only the required service account or administrator can read it.
# Secure permissions for a private key chmod 600 private.key chown root:root private.key
Once the files are created or converted, it is wise to verify that the certificate, private key, and CSR all belong together. A classic mistake is trying to use a certificate with the wrong private key. In that case Apache or NGINX usually refuses to load or reports that the private key does not match the certificate. A very practical habit is to compare the modulus or similar output from OpenSSL before deploying the files. It takes little time and avoids much longer troubleshooting later.
# Check whether the key matches the certificate openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in private.key | openssl md5 # Inspect the CSR and certificate openssl req -noout -text -in request.csr openssl x509 -noout -text -in server.crt
Self-signed certificates are another common scenario. They are useful for internal labs, development systems, private test services, and temporary non-public environments. But a self-signed certificate is not the same thing as a publicly trusted SSL certificate. If a public-facing website uses a self-signed certificate, browsers will display warnings because the issuing authority is not trusted by default. For internal use that may be acceptable, but for customer-facing services it usually is not.
# Create a self-signed certificate openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out server.crt
Validation, deployment, and common mistakes
After preparing PEM files, the next step is deployment on the server. Apache, NGINX, and other services have different configuration syntax, but the logic is the same: the server must know where the certificate file is and where the matching private key is, and in many cases it also needs the chain or fullchain file. In production environments it is best not to reload the service blindly. First test the configuration, then reload or restart only when the syntax and file paths are confirmed to be correct.
# Test NGINX configuration nginx -t # Test Apache configuration apachectl configtest
The most common PEM-related mistakes are incorrect fullchain order, mixing up the leaf certificate and intermediate chain, using the wrong private key, applying insecure permissions, and storing sensitive files in locations that are too widely readable. Another very common operational issue is forgetting the expiry date. The certificate may be technically valid today, but if there is no renewal process or monitoring, an expired certificate causes the same visible trust problem as a broken one.
Best practice is to document where the certificate came from, which private key belongs to it, which service uses it, where the chain file is stored, and when the certificate expires. This becomes especially important in environments with multiple domains or multiple administrators. PEM itself is not difficult, but confusion grows quickly when nobody remembers why a specific file was created or which service depends on it.
Once the process is understood properly, creating and handling PEM certificates becomes routine. You know how to generate a key, create a CSR, receive the issued certificate, build a full chain, convert other formats, and validate that every part matches. That structured understanding is what makes it possible not only to “fix SSL” once, but to manage HTTPS cleanly and safely over the long term.