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:0B080074:
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.
Related
I'm trying to have a server A communicate with a server B through HTTPS requests. Server B has a certificate that was issued to me by my employer, and connecting to it through both Safari and Chrome works without any issues.
However, when trying to send a request from A to B through Guzzle, I get the following error:
GuzzleHttp/Exception/RequestException with message 'cURL error 60: SSL certificate problem:
unable to get local issuer certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)'
I've tried setting the cert file as a parameter ( [verify => '/path/to/cert.pem'] ), but, first of all, I only had .crt, .csr and .key files; I tried making a .pem file through these instructions I found somewhere else:
(optional) Remove the password from the Private Key by following the steps listed below:
openssl rsa -in server.key -out nopassword.key
Note: Enter the pass phrase of the Private Key.
Combine the private key, public certificate and any 3rd party intermediate certificate files:
cat nopassword.key > server.pem
cat server.crt >> server.pem
Note: Repeat this step as needed for third-party certificate chain files, bundles, etc:
cat intermediate.crt >> server.pem
This didn't work – the error's the same. The request works with 'verify' set to false, but that's obviously not an option for production.
Certificates are not something I usually work with, so I'm having a lot of trouble just figuring out where the issue might lie, let alone fix it. Any help would be much appreciated.
Edit
I've also tried the solutions suggested in Guzzle Curl Error 60 SSL unable to get local issuer to no avail.
This was happening because the only certificate I had configured on server B was the End User certificate.
I'm new to this, so my explanation will probably be flawed, but from my understanding End User certificates link back to a trusted Certificate Authority (CA) certificate, with zero or more intermediate certificates in-between. Browsers can figure out this certificate chain, and download the required certificates that are missing; cURL does not.
Therefore, the solution was configuring Server B with the missing certificates. How to do this is a whole different issue, so I won't go into it in this answer.
It's been 2 full days that I'm trying to sign my exe using SignTool and kSign. I bought a SSL certificate from COMODO for my domain (used for https on apache). Now I'm trying to sign my exe using the same certificate and the same private key used. I'm using the commands:
openssl pkcs12 -inkey example.com.key -in example.com.crt -export -out example.com.pfx
and trying to sign it
signtool /f example.com.pfx /p mypassword myexe.exe
and I always get: "SignTool Error: No certificates were found that met all the given criteria."
Whatever ways I found to generate PFX files from the Internet, it's always that same error message. I even tried to sign it with kSign and I get the same thing. What I am missing? Can I use a SSL certificate I bought for my web server for signing my exe files also?
Thanks.
The problem was, I tried to sign an application using a SSL certificate. That didn't work because SSl certificates is different from code signing certificate, which is the one I need.
I've found the problem by running
certmgr.exe
and then importing the certificate into the personal store.
I had the same error, my PFX file had an expired certificate.
I've currently encountered a unique issue. To help understand the predicament I'll provide some background. Our company hired a third-party to develop an application, apart of this web application package was the purchase of an SSL Certificate.
After they purchased the SSL they exported it into a Personal Information Exchange (.pfx).
The issue now occurs here...
Our company web-server utilizes the Plesk Panel 11. Which complicates matters for two reasons.
The first is that if I directly install the certificate Plesk will
not recgonize the certificate and will eventually overwrite the
contents in our Microsoft Certificate Store within the Windows
Server MMC Certificate Snap-In.
The second issue is sheer bad luck, Plesk doesn't recognize the .pfx extension. It apparently only understands the following:
Private Key (.key)
Certificate (.crt)
CA Certificate (-ca.crt)
So my original thought was to simply convert the file into a valid format, which resulted in an error. The second attempt was to follow a command line control to export the file format to the valid extension. The results are still disappointing:
Error: Invalid Certificate Format
Since the file installed was a .pfx it does not allow me to convert it to anything else. Unfortunately when utilizing Open SSL it only converted to a .pem. Which to my dismay is also unsupported-
Any assistance would be terrific.
Update:
I attempted to follow this question on Stack Overflow. Unfortunately Windows Server 2012 doesn't appear to do the conversion as well. It does convert it into a valid format, but then the Private Key can't be found.
In order to solve this issue I followed this blog here.
So I attempted to utilize Open SSL again, with these steps:
// Extract Private Key
openssl pkcs12 -in [yourfile.pfx] -nocerts -out [keyfile-encrypted.key]
// Extract Certificate
openssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [certificate.crt]
// Encrypted Private Key
openssl rsa -in [keyfile-encrypted.key] -out [keyfile-decrypted.key]
Again you need to enter an import password. This time you need to enter the new password that you created in step 1. After that you’re done. You decrypted your private key. In the folder you ran OpenSSL from you’ll find the certifcate (.crt) and the two private keys (encrypted and unencrypted).
That is how I solved my question.
I have requested a class 1 certificate from StartSSL and installed it in Weblogic 10.0.1 (see screenshots).
The browsers (Chrome & IE9 on Windows 7, IE8 on XPSP3) still give a certificate error (see screenshots).
I think the StartSSL root certificate is available in several browsers (see here). Please advise.
StartSSL Class 1 certificates are signed by a intermediate CA, which is signed by the StartCom Root CA. For your browser to trust this certificate, it needs to know the trust chain up to the Root CA it already knows.
Your server needs to send the complete trust chain to the browser (minus the Root CA), so your browser can verify that your certificate is trusted.
See the StartSSL FAQ for more info.
Found the problem. I've imported the StartSSL certificate incorrectly in our keystore. Also, I've specified "weblogic" as alias in the Weblogic console which is not the certificate but the public/private key pair. I'm using Portecle to edit the keystore.
When I've noticed that I was probably using the wrong alias I've changed it to the alias of the certificate. This resulted in a Weblogic error:
Inconsistent security configuration, weblogic.management.configuration.ConfigurationException: No identity key/certificate entry was found under alias startssl-hostname in keystore keystore_StartSSL on server servername
In the end I've followed these steps to pack the certificate and private key in one PKCS#12 keystore. I've then imported that keystore into our java keystore using Portecle:
Export the "weblogic" public/private key using Portecle as a PKCS#12 keystore.
Extract the private key from this keystore using openssl:
openssl pkcs12 -in weblogic.p12 -nocerts -out privatekey.pem
Package the certificate and private key as a PKCS#12 keystore (cert.p12) using openssl:
openssl pkcs12 -export -in cert.cer -inkey privatekey.pem -out cert.p12 -name cert -CAfile ca.pem -caname root
Import cert.p12 file into our java keystore using Portecle using "cert" as alias.
Changed the Weblogic configuration to use the "cert" alias with the correct passphrase.
And it worked!
PS: I've added the JCE unlimited strength policy along the way since Portecle complained about this at one point.
Generally the trust store and keystore would be separate, but it will not cause the error above.
If your browser does not trust the CA then you will receive the above error. You need to add the root CA to your browser. You can check the certs that your browser supports.
Eg for IE -> Tools -> Internet Options -> Content -> Certificates -> Trusted Root CA
Assuming you need to import this into one or two browsers, its not a big deal. But if you need to do this across the enterprise (meaning 100 or 1000 of browsers), you will need help from your desktop support team !
I'm confused about something in the SSL renewal process using WHM/cPanel for an existing Comodo Extended Validation cert.
We have been issued a replacement certificate by Comodo without - I believe - every submitting a CSR for them. I say "I believe" because there are 3 people with access to WHM for this server, but I'm assured that no one has been fiddling in the last year.
Does this sound possible? CAN a cert be supplied without a CSR if it's a replacement? I will attempt to get hold of Comodo but being a weekend, and seeing that the old cert runs out in a day I thought I'd consult the stackHiveMind :)
More info:
As a test, I've tried to install the new cert and 'fetch' the existing private key, but when I try to submit that I get the following error:
SSL install aborted due to error: Modulus mismatch, key file does not match certificate. Please use the correct key file
In some cases, yes, you can. Assuming you have an RSA private key in PEM format, this will extract the public key (it won't generate a certificate):
openssl rsa -in key.pem -pubout -out pubkey.pem
This will create a new CSR with the public key, obtained from the private key file.
openssl req -new -key key.pem -out host.csr
Note that, strictly speaking, a CA doesn't need you to submit a CSR to issue a certificate. All it needs is the public key (to which it will have access through your existing cert). It could potentially attach any Subject DN and attribute and issue it as a certificate without any need to contact you. Of course such practices might be incompatible with their policies, but technically, it's possible. The CSR is merely a convenient format for you to send a public key to request a certificate, and submit the name and attributes you would like (which you all sign together).
SSL install aborted due to error: Modulus mismatch, key file does not
match certificate. Please use the correct key file
Provided you've done the certificate operations properly, this could indicate that the new certificate you've been issued has been issued against a different key-pair than yours. This could indicate foul play, because someone else could have issued a CSR with their own key-pair and have had this certificate issued to them (which could be quite worrying since you're talking of an EV cert too, which is supposed to have additional protections against this.)
I would suggest checking with your colleagues if any have requested a new certificate or contacting your CA to find out why you've received a new certificate. Renewing the certificate using the previous public key might be part of their existing package. If it's using the same public key, it's not a problem, although it's better practice to change the key material, i.e. submit a CSR coming from a new key-pair, when renewing a certificate.