Once you have established that they don't match, you still have a problem -- what to do about it. Often, the certificate may merely be assembled incorrectly. When a CA signs your certificate, they send you a block that looks something like
-----BEGIN CERTIFICATE-----
MIIAA-and-a-buncha-nonsense-that-is-your-certificate
-and-a-buncha-nonsense-that-is-your-certificate-and-
a-buncha-nonsense-that-is-your-certificate-and-a-bun
cha-nonsense-that-is-your-certificate-and-a-buncha-n
onsense-that-is-your-certificate-AA+
-----END CERTIFICATE-----
they'll also send you a bundle (often two certificates) that represent their authority to grant you a certificate. this will look something like
-----BEGIN CERTIFICATE-----
MIICC-this-is-the-certificate-that-signed-your-request
-this-is-the-certificate-that-signed-your-request-this
-is-the-certificate-that-signed-your-request-this-is-t
he-certificate-that-signed-your-request-this-is-the-ce
rtificate-that-signed-your-request-A
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICC-this-is-the-certificate-that-signed-for-that-one
-this-is-the-certificate-that-signed-for-that-one-this
-is-the-certificate-that-signed-for-that-one-this-is-t
he-certificate-that-signed-for-that-one-this-is-the-ce
rtificate-that-signed-for-that-one-this-is-the-certifi
cate-that-signed-for-that-one-AA
-----END CERTIFICATE-----
except that unfortunately, they won't be so clearly labeled.
a common practice, then, is to bundle these all up into one file -- your certificate, then the signing certificates. But since they aren't easily distinguished, it sometimes happens that someone accidentally puts them in the other order -- signing certs, then the final cert -- without noticing. In that case, your cert will not match your key.
You can test to see what the cert thinks it represents by running
openssl x509 -noout -text -in yourcert.cert
Near the top, you should see "Subject:" and then stuff that looks like your data. If instead it lookslike your CA, your bundle is probably in the wrong order; you might try making a backup, and then moving the last cert to the beginning, hoping that is the one that is your cert.
If this doesn't work, you might just have to get the cert re-issued. When I make a CSR, I like to clearly label what server it's for (instead of just ssl.key or server.key) and make a copy of it with the date in the name, like mydomain.20150306.key etc. that way they private and public key pairs are unlikely to get mixed up with another set.
Check an MD5 hash of the public key to ensure that it matches with what is in a private key
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
I had this problem because i was adding bundle and certificate in wrong order so maybe this could help someone else.
Before (which is wrong) :
cat ca_bundle.crt certificate.crt > bundle_chained.crt
After (which is right)
cat certificate.crt ca_bundle.crt > bundle_chained.crt
And Please don't forget to update the appropriate conf (ssl_certificate must now point to the chained crt) as
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate bundle_chained.crt;
ssl_certificate_key www.example.com.key;
...
}
From the nginx manpage:
If the server certificate and the bundle have been concatenated in the wrong order, nginx will fail to start and will display the error message:
SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)
I got a MD5 hash with different results for both key and certificate.
This says it all. You have a mismatch between your key and certificate.
The modulus should match. Make sure you have correct key.
If this happens and you are using Let's Encrypt / certbot, the reason is most likely that you used chain.pem
instead of fullchain.pem
.
It should be something like this:
ssl_certificate /etc/certbot/live/example.com/fullchain.pem;
ssl_certificate_key /etc/certbot/live/example.com/privkey.pem;
See certbot docs “Where are my certificates?”
I had the same problem and finally resolved it by changing the order of pem blocks in certificate file.
The cert block should be put in the beginning of the file, then intermediate blocks, then root block.
I realized this problem by comparing a problematic certificate file with a working certificate file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With