Certificates & Site Ops
Fix NGINX key values mismatch
Fix NGINX key values mismatch by checking the active certificate, private key, and bundle order. Compare RSA or EC public keys before testing the configuration.
NGINX can report key values mismatch when the certificate it loads does not contain the public key corresponding to the configured private key. A different private-key file is one cause. A bundle with the intermediate certificate first can cause the same error even when the intended server certificate and private key match.
Compare the public key from the first certificate in the configured file with the public key derived from the configured private key. That distinguishes the two cases before you replace files or request another certificate.
Find the files in the active configuration
Read the ssl_certificate and ssl_certificate_key directives for the affected server block. A typical PEM configuration looks like this:
ssl_certificate /etc/nginx/tls/fullchain.pem;
ssl_certificate_key /etc/nginx/tls/site.key;
Use the same NGINX executable, prefix, and configuration path as the running service. nginx -T tests and prints the configuration, including included files; if a test stops at the TLS error, inspect the named configuration and its includes directly. Check which server block and certificate/key pair the error refers to, especially when RSA and EC certificates are both configured.
Tip: Compare the files at the paths NGINX actually loads. A matching pair in your download directory does not establish which certificate a deployed bundle, symlink, container mount, or included configuration selects.
These steps cover PEM certificate files with file-based keys. Configurations that obtain keys from a provider or hardware device need the corresponding provider-specific checks.
Compare public-key fingerprints for RSA or EC
The following commands hash the DER-encoded public key from each file. Replace fullchain.pem and site.key with the configured paths. The first pipeline reads the first certificate in the bundle.
set -o pipefail
openssl x509 -in fullchain.pem -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256
openssl pkey -in site.key -pubout -outform DER |
openssl dgst -sha256
For a matching pair, both successful pipelines print the same SHA-256 digest. An encrypted key may prompt for its passphrase. Check command errors as well as the digest: pipefail makes an upstream failure visible in shells such as Bash and zsh.
This uses public-key extraction rather than an RSA modulus comparison, so the same procedure works for RSA and EC keys. It also avoids comparing a whole-certificate fingerprint with a key fingerprint: those hash different data. The OpenSSL pkey command documents public-key output and DER encoding.
Case A: the leaf matches, but the bundle starts with an intermediate
Suppose leaf.pem contains the server certificate and intermediate.pem contains its issuer. Compare leaf.pem with site.key using the commands above, then repeat the certificate command using fullchain.pem.
| Comparison | Expected result when the bundle is reversed |
|---|---|
leaf.pem public key vs site.key public key |
Equal digests |
fullchain.pem first public key vs site.key public key |
Different digests |
First certificate in fullchain.pem |
Intermediate, rather than server certificate |
This identifies a matching leaf/key pair that NGINX is not loading as the first certificate. The official NGINX HTTPS configuration guide documents this bundle-order cause of key values mismatch.
Build a new bundle with the server certificate first, followed by its intermediate chain in issuer order:
cat leaf.pem intermediate.pem > fullchain-candidate.pem
openssl x509 -in fullchain-candidate.pem -noout -subject -issuer
For multiple intermediates, place the one that issued the leaf immediately after it, then that intermediate's issuer. Check the candidate's first public-key fingerprint against site.key again. Use the Certificate Chain Checker to inspect the certificate sequence, or read the general certificate bundle-order guide for a longer chain example.
Case B: the private key belongs to a different certificate
If the standalone leaf certificate and configured private key produce different public-key digests, reordering intermediates cannot make that pair match.
| Comparison | Expected result with a genuinely wrong key |
|---|---|
leaf.pem public key vs the correct site.key |
Equal digests |
leaf.pem public key vs other.key |
Different digests |
Correctly ordered bundle vs other.key |
Still different |
Find the key created with the certificate request, or select the certificate issued for the intended key. Generating a new unrelated key does not make it match an existing certificate. If the original key is unavailable, create a new key and certificate request and have a certificate issued for that new public key.
The two cases above were tested with temporary synthetic RSA and EC certificates using OpenSSL 3.5.1. A correctly ordered chain loaded with its matching key; a reversed chain and a different key each produced a key-mismatch error when loaded into an offline TLS context. The comparison commands require no running server.
Test the corrected configuration before reload
After selecting the matching pair and correctly ordered bundle, test the configuration using the service's normal invocation. For a default installation:
nginx -t
If the service uses an explicit configuration path, carry that into the test, for example nginx -t -c /etc/nginx/nginx.conf. A successful test confirms that NGINX can parse that configuration and open the referenced files. Certificate names, expiry, the served chain, and client trust still need their own checks before you consider the deployment complete.
If the fingerprints match but testing still fails, read the new error and verify the actual paths, file formats, passphrase handling, and other configured certificate/key pairs. Reload only after the configuration test succeeds and you are ready to apply the change.
Related tools
- Certificate & Key Matcher for comparing a certificate with a key.
- Certificate Chain Checker for inspecting bundle order and issuer relationships.
- X.509 Certificate Parser for reading the first certificate's subject, issuer, dates, and public-key details.
