🚨 Nginx Error: 'PEM routines:get_name:no start line ... Expecting: ANY PRIVATE KEY' — Cause, Fix, and Troubleshooting Guide

What this error means

This is a config-load [emerg] raised while nginx hands your ssl_certificate_key file to OpenSSL. no start line means OpenSSL scanned the file for a PEM header — a line like -----BEGIN PRIVATE KEY----- — and reached the end without finding one. The Expecting: ANY PRIVATE KEY clause tells you it was specifically looking for a private key and got something that is not a well-formed PEM private key. nginx aborts and does not start or reload.

2026/07/12 10:02:38 [emerg] 30871#30871: SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/example.com.key") failed (SSL: error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY) in /etc/nginx/sites-enabled/example.com.conf:13

Unlike a “cannot load certificate / No such file” error, the file here exists and is readable — its contents are the problem. TLS stays down for that server block until the key file is replaced with a valid PEM.

How the server responds

• [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: ...PEM routines:get_name:no start line...) on start/reload/nginx -t.
• The same no start line reason can appear for SSL_CTX_use_certificate_chain_file when it is the certificate file that is malformed.
• nginx -t fails; the service refuses to start or reload and old workers keep serving.
• The referenced key file is present and non-empty in ls -l, so it is not a missing-file problem.
• openssl rsa/openssl pkey on the same file also errors with no start line or unable to load key.
• Often appears immediately after a copy/paste, a bad templating render, or converting a key with the wrong tool.

Testing the server configuration

Reproduce with a config test so you get the exact reason without disturbing running workers:

sudo nginx -t

Find the precise path nginx is loading as the key:

sudo nginx -T 2>/dev/null | grep -nE 'ssl_certificate_key\s'

Inspect the top of the file — you are checking for a real PEM header, no BOM, and Unix line endings:

head -c 64 /etc/nginx/ssl/example.com.key | xxd | head   # BOM shows as ef bb bf
head -n1  /etc/nginx/ssl/example.com.key                 # should be -----BEGIN ... PRIVATE KEY-----
file /etc/nginx/ssl/example.com.key                      # "PEM ... private key" vs "data" (DER)
wc -c /etc/nginx/ssl/example.com.key                     # not 0 bytes / not truncated
grep -c 'BEGIN' /etc/nginx/ssl/example.com.key           # 0 means no PEM header at all

Ask OpenSSL to parse the key directly — this is the ground truth nginx relies on:

openssl pkey -in /etc/nginx/ssl/example.com.key -noout -text | head
# Legacy RSA form:
openssl rsa  -in /etc/nginx/ssl/example.com.key -check -noout

Confirm you did not swap cert and key — the “key” file should NOT contain a certificate:

grep -m1 'BEGIN' /etc/nginx/ssl/example.com.key
# If it prints "-----BEGIN CERTIFICATE-----", the wrong file is in ssl_certificate_key.

Check for CRLF line endings, which corrupt PEM parsing:

cat -A /etc/nginx/ssl/example.com.key | grep -m1 '\^M'   # ^M$ indicates CRLF

Server configuration causes

• Wrong file in the key slot — ssl_certificate_key points at the certificate (or a CSR, or a chain) instead of the private key. OpenSSL finds BEGIN CERTIFICATE, not a key header, and reports it was expecting a private key.
• DER (binary) instead of PEM — the file is a raw DER/PKCS#8/PKCS#12 blob with no -----BEGIN----- armor. nginx expects PEM; there is no start line to find.
• Empty or truncated file — a failed scp/redirect wrote a 0-byte or half-written file; the BEGIN line is missing or the body is cut off.
• Header/footer damaged or reformatted — copy-paste through chat/tickets stripped the -----BEGIN/END----- lines, unwrapped the base64, or turned dashes into unicode look-alikes.
• Leading BOM or whitespace before -----BEGIN — a UTF-8 byte-order mark or blank lines ahead of the header make OpenSSL miss the start line. (Extra content after a valid key is usually tolerated; content before the first header is not.)
• CRLF / templating artifacts — a key rendered by a CI templating step gained \r\n line endings, HTML-escaped characters, or was double-base64-encoded, corrupting the PEM structure.

The fix

If the file is DER, convert it to PEM (pick the form matching the input):

# DER private key -> PEM
openssl pkey -inform DER -in example.com.key.der -out /etc/nginx/ssl/example.com.key

# Extract key from a PKCS#12 bundle -> PEM (you will be prompted for the export password)
openssl pkcs12 -in example.com.pfx -nocerts -nodes -out /etc/nginx/ssl/example.com.key

If a BOM or CRLF endings crept in, strip them so the header is the very first bytes and lines are LF-only:

sed -i '1s/^\xEF\xBB\xBF//' /etc/nginx/ssl/example.com.key   # remove UTF-8 BOM
sed -i 's/\r$//'            /etc/nginx/ssl/example.com.key    # CRLF -> LF

If the file is truncated, empty, or the wrong file entirely, replace it with the correct, complete PEM private key. A valid file looks exactly like this (headers on their own lines, base64 body wrapped, nothing before the first header):

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQ...   (redacted)
...
-----END PRIVATE KEY-----

Point the directives at the corrected files and keep the key permissions tight:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;   # cert / fullchain
    ssl_certificate_key /etc/nginx/ssl/example.com.key;   # private key ONLY
}

sudo chown root:root /etc/nginx/ssl/example.com.key
sudo chmod 0600      /etc/nginx/ssl/example.com.key

After replacing the key, validate and reload — use restart/start if the service was fully down because it failed to load:

sudo nginx -t && sudo systemctl reload nginx
# If nginx never started: sudo systemctl restart nginx

Safe configuration practice

• Verify keys with openssl pkey -in <file> -noout in CI before deploy; a key that fails there will always fail nginx load with no start line.
• Never move private keys through chat, tickets, or copy-paste — it silently strips headers, unwraps base64, and injects unicode dashes. Use scp/secret stores and checksum after transfer.
• Ensure your templating/secret tooling emits LF line endings and no BOM; CRLF and BOMs are the most common invisible causes.
• Keep the certificate and the key in separate files with clear names, and never let the ssl_certificate_key path point at a .crt/.pem chain.
• Store the key 0600 root:root; a public certificate can be 0644, but the key must not be world-readable.
• Alert on nginx [emerg] at startup so a bad key surfaces at deploy time, not on the next restart. Surface it on your monitoring dashboard.

Related server errors

• Nginx Error: Ssl Private Key Mismatch — once the key parses, this is the error when it does not match the certificate.
• Nginx Error: Ssl Handshake Certificate — runtime trust/chain failures after the key and cert load cleanly.
• Nginx Error: Ssl Do Handshake Failed — protocol and cipher negotiation errors distinct from PEM parsing.

See the NGINX category for more guides.