SSL install problem - "key value mismatch" (but they do match?)

So I've been sent a new public cert to install on a server (.crt file). Done. Restart apache - "FAILED".

Error message:

[Tue Jan 11 12:51:37 2011] [error] Unable to configure RSA server private key 
[Tue Jan 11 12:51:37 2011] [error] SSL Library Error: 185073780 error:0B0开发者_JS百科80074:
x509 certificate routines:X509_check_private_key:key values mismatch

I've checked the key values:

openssl rsa -noout -modulus -in server.key | openssl md5
openssl x509 -noout -modulus -in server.crt | openssl md5

and they DO match.

I've checked the paths in my ssl.conf file, and they ARE pointing to the correct files.

If I reinstate the old (expired) cert file, apache starts up ok, so it definitely doesn't like something about the new one.

It's a GeoTrust QuickSSL, and it came with an "intermediate.crt" that I'm supposed to use in place of the the "ca-bundle.crt" file that I was using before

SSLCertificateFile /etc/pki/tls/certs/www.domain.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.domain.com.key
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

Any ideas what I might be doing wrong? Any more info you need?

Thanks!

I also came across the same error. In my case I had to supply additional CA certificates in the verification chain. And instead of supplying the certificate and the key in separate files, I combined them in a .pem file.

However, when you do this, the order of the key and the certificate plus the intermediate one(s) is important. The correct order:

your private key
your certificate
(intermediate) CA certificate lowest in the hierarchy
other CA certificates higher in the hierarchy...
(intermediate) CA certificate highest in the hierarchy

I had the same issue on one of my CentOS 6.5 servers recently and it was down to when I generated the KEY and CSR.

I have three sites running on this server in virtualhosts all with dedicated IPs and each site has its own SSL Certificate.

In a rush, when changing one of the certificates, I stupidly just followed the certificate provider's guide to gaining the CSR and installing it in Apache, and I was instructed to use the following command:

openssl req -new -newkey rsa:2048 -nodes -keyout domain-name-here.key -out domain-name-here.csr

After installing the new certificate I was then also facing Apache not starting and the same errors in /var/log/httpd/ssl_error_log:

[error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

[error] Unable to configure RSA server private key

Now what I really should have done was check my .bash_history files, as I have successfully done this in CentOS many times before.

I should have run these two commands instead :

openssl genrsa -des3 -out domain-name-here.co.uk.key 2048

openssl req -new -key domain-name-here.co.uk.key -out domain-name-here.co.uk.csr

This then successfully generated the CSR and KEY, and I re-applied for the certificate using the newly gained CSR, then applied the new certificate and added the new key file and finally then Apache would start cleanly.

Also, just to note, after a little configuration we now score A+ in an SSL labs test.

When reissuing my Rapid SSL certificate (purchased through Namecheap) to deal with the Heartbeat bug, the new certificate was always issued against the private key used for the previous CSR request. After about the fifth reissue, pairing that with the private key used in the fourth reissue attempt made things work fine.

make sure all cert files are encoded using ANSI, not UTF-8.

For me all tests said: key, crt and csr do match, but the logs said X509_check_private_key:key values mismatch until I saw that one of the files was encoded in UTF-8.

In my case, I had two sites and two subtley different private keys:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/some/path/server.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)

After I fixed that, the error message changed to mention /some/path/server.pem. Note the different private key, which only differed in file extension. I had 2 different sites encrypted with different keys (meaning I had fixed the first site but now needed to fix the second site). So be sure to read the error message carefully!

We also had the issue with NameCheap, the issued Cert matched the CSR that was used to generate the previous CERT. We let them know via their support page, and they said they already knew about the issue.

According the FAQ on the Apache website, the modulus and the public exponent for the cert and the key must match so that is a valid check.

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#verify

As you and others have already stated, work with the cert issuer

The trickiest bit in my case is setting up the SSLCACertificateFile. Once the certificate company issued our cert, alongside it we received two additional certs: an intermediate and a root certificate. Which one to use for SSLCACertificateFile? Both..

Here's what my certificate chain look like:

And for the SSLCACertificateFile I have to concatenate digicert_sha2_high_assurance_server_ca.crt and digicert.crt into one file in the mentioned order.

Dynadot seem to have the same issues with the RapidSSL certificates they are re-issuing. I just received a non working certificate, which then triggered another issue with Apache, when that was fixed I found this question and answer here for the original problem, thanks for the information everybody. I shall be scrapping the RapidSSL Cert as I have some client compatibility issues with it anyway and purchasing a new one from AlphaSSL instead.