nginx · troubleshooting

SSL_CTX_use_PrivateKey failed: key values mismatch

The private key nginx loaded does not belong to the certificate it loaded first. Usually the wrong key file, a key from before a renewal, or a chain file with the certificates in the wrong order.

Reproduced on nginx 1.24.0, 23 Oct 2026. Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published 23 Oct 2026

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

Read access to the certificate and key files named in the nginx configuration (often root only).

Run this first

step 1 of 2

sudo nginx -T 2>/dev/null | grep -n 'ssl_certificate'

Look for The pair for the server block that fails

Shows exactly which certificate and key files nginx is configured with, including included files.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Do the public-key hashes of the certificate and key match?

Cause space

2 of 2 still possible

The key file belongs to a different certificateCommon
The chain file starts with the intermediate, not your certificateCommon

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

Step 1
```
sudo nginx -T 2>/dev/null | grep -n 'ssl_certificate'
```
Shows exactly which certificate and key files nginx is configured with, including included files.
Look for The pair for the server block that fails
Step 2
```
openssl x509 -in CERT.pem -noout -pubkey | sha256sum; openssl pkey -in KEY.pem -pubout | sha256sum
```
Compares the public key inside the certificate with the one derived from the private key. Works for RSA and ECDSA.
Look for Identical hashes when the pair matches

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

The key file belongs to a different certificate

Common

A renewal or re-issue created a new key and the configuration still points at the old one, or two sites' files were swapped.

Confirm

openssl x509 -in CERT.pem -noout -pubkey | sha256sum
openssl pkey -in KEY.pem -pubout | sha256sum

Two different hashes

Fix

Find the key whose hash matches the certificate's, and set ssl_certificate_key to it.
With certbot, use the fullchain.pem and privkey.pem from the same live/DOMAIN directory; a second directory such as DOMAIN-0001 is a separate certificate with its own key.
Then nginx -t, and reload only when it passes.

sudo nginx -t && sudo systemctl reload nginx

nginx -t passed on nginx 1.24.0 once the key matched.

The chain file starts with the intermediate, not your certificate

Common

Certificates concatenated in the wrong order: nginx treats the first certificate in ssl_certificate as yours.

Confirm

openssl x509 -in FULLCHAIN.pem -noout -subject

The subject of an intermediate or CA instead of your domain

Fix

Rebuild the file with your certificate first: cat server.crt intermediate.crt > fullchain.pem. The nginx HTTPS guide shows this same error for a bundle in the wrong order.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

A certificate contains a public key, and it only works with the one private key made alongside it. nginx checks that the two match when it reads its configuration, and refuses to start or reload if they do not. Find which files actually belong together, and point nginx at those.

Words used on this page

Key pair: A private key and its public key. The certificate carries the public half.
Full chain: One file with your server certificate first, then the intermediate certificates. nginx pairs the key with the first certificate in it.

What is actually happeningadvanced

Reproduced on 23 October 2026 on Ubuntu 24.04 with nginx 1.24.0 and OpenSSL 3.0.13, using throwaway self-signed certificates and nginx -t on a temporary configuration. A certificate paired with another certificate's key gave [emerg] SSL_CTX_use_PrivateKey("…/b.key") failed (SSL: error:05800074:x509 certificate routines::key values mismatch), and the configuration test failed.

The order inside a chain file matters. With the CA certificate first and the server certificate second, the same correct key failed with the same error; with the server certificate first, the test passed.

OpenSSL reports the same check as X509_check_private_key:key values mismatch, so other servers built on OpenSSL fail with the same words.

How to tell this is your problemsignals

Where	What you see
nginx -t, or systemctl reload nginx	[emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/site.key") failed (SSL: error:05800074:x509 certificate routines::key values mismatch)
openssl s_server and other OpenSSL programs	X509_check_private_key:key values mismatch

How to know it is actually fixed

nginx -t prints test is successful, and the site serves the expected certificate after the reload.

Stopping it happening again

Always run nginx -t before a reload, and make renewal hooks do the same.
Point nginx at the files your certificate tool maintains, rather than copies that can drift apart.

Security considerations

Never paste a private key into a website or chat to check it. The comparison below prints only a hash of the public key, which is safe to share.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it