I received my certificate by email and then created the necessary files and copied it over. I went to restart my server and received the following errors.
[Wed Feb 08 13:02:06 2012] [error] Init: Unable to read server certificate from file /home/sslcertificates/mydomain.crt
[Wed Feb 08 13:02:06 2012] [error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Wed Feb 08 13:02:06 2012] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
Does anyone have any ideas?
Another possible source of failure which causes this errror message is:
Instead of the certificate file I linked to the certification request file.
It's recognizable when you read the first line of the file:
Either
-----BEGIN CERTIFICATE REQUEST-----
Or
-----BEGIN CERTIFICATE-----
:-)
Situation: Apache 2.4 using the StartSSL cert generating ASN encoding error
Issue:
AH02564: Failed to configure encrypted (?) private key <domain>.com:80:0, check /etc/pki/tls/certs/ssl.key
Some SSL issuers encrypts the ssl key files by default so make sure decrypt it at the server and point it from Virtual Host.
Simply echo the key file to make sure it is not encrypted.
Decrypt the key file for the mod_ssl
openssl rsa -in ssl.key -out ssl.key
For SSL config in the Apache conf (httpd.conf) add the following configurations and restart the Apache.
# SSL
<VirtualHost *:443>
ServerName gajen.com
SSLCertificateKeyFile /etc/pki/tls/certs/ssl.key
SSLCertificateFile /etc/pki/tls/certs/ssl.crt
SSLCertificateChainFile /etc/pki/tls/certs/root.ca.pem
</VirtualHost>
For troubleshooting:
Debug the Apache first tail 50 /var/log/httpd/error_log
Debug the mod_ssl tail 50 /var/log/httpd/ssl_error_log
In my case I had the certificates mixed: SSLCertificateFile had the private_key and SSLCertificateKeyFile had the cert.
Leaving this here since it's the first google search for the error: This can also be caused when you install a new passphrase protected certificate and just reload the apache configuration (rather then restart apache completely). The reload itself will not throw any errors but it also will not ask for your passphrase and is unable to decrypt the certificate.
It can be resolved by restarting apache completely which will ask for the passphrase and allow you to decrypt.
Problem solved with recreate *.key file and copy-paste content again.
Or you need before disable old password autoinput.
Comment rule like:
#SSLPassPhraseDialog exec:/etc/ssl/passphrase-script
Recently during SSL installation in Apache 2.4, we faced the same error - 'asn1 encoding routines'
We had placed all the files correctly and pointed them correctly in the .conf file. After a day of troublshooting,we realized issue was not with the configuration after we got the certificate.
We created the Certificate Signing request (CSR) using our vendors inbuilt system. This allowed us to paste the key we created. The SSL certificate which vendor returned was supposed to map this CSR which was mapped to our private key. Apparently it did not match. The SSL certificate they provided does not map to the CSR.
Possible reason
The Key to CSR transformation is wrong at vendor side due to unix line endings (\n instead of \r\n) / encoding (ANSI/UTF8) / expected new lines .
We created CSR ourselves using OpenSSL, and bypassed vendor CSR generation. It worked. So, in our case, creating the key and corresponding CSR using OpenSSL and using that to generate the public SSL worked.
OpenSSL Command
openssl req -new -sha256 -key ~/site.com.ssl/site.com.key -out ~/site.com.ssl/site.com.csr
I had this problem because I was sent the content of an IIS-style .p7b file pasted into an email. It has "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" tags, just like .pem, and the content uses a similar looking base64 encoding. I converted it to a *.pem file like so:
openssl pkcs7 -print_certs -in cert.p7b -out cert.cer
After that, Apache 2.2 was happy.
(Linux Solution) This has been posted a long time ago - but I have another way to troubleshoot this problem: Change the error logging to a more verbose mode by editing /etc/apache2.conf and find this block:
#
# LogLevel: Control the severity of messages logged to the
error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
LogLevel warn
and change LogLevel to something lower - I chose trace1. Then restart apache:
sudo service restart apache2
I received the same error message but when I went to the error log in /var/log/apache2/error.log there were many more error messages to help troubleshoot the problem. I was able to determine I was pointing the key file descriptor to the wrong file.
Be sure to change the apache2.conf back to warn and restart the apache2 service after troubleshooting to avoid your error.log file from becoming too large.
Related
I got valid https certificate from Let's Encrypt, but have trust issues giving it to vert.x version 3.6.2
I tested the cert with apache, it's ok, however if I try to reach the https vert.x server instance with wget I get:
$ wget https://www.myhost.mydomain/json/read/all-languages
--2019-01-22 10:30:56-- https://www.myhost.mydomain/json/read/all-languages
Resolving www.myhost.mydomain (www.myhost.mydomain)... 88.14.34.156
Connecting to www.myhost.mydomain >(www.myhost.mydomain)|88.14.34.156|:443... connected.
ERROR: cannot verify www.myhost.mydomain's certificate, issued by >‘CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US’:
Unable to locally verify the issuer's authority.
To connect to www.myhost.mydomain insecurely, use `--no-check->certificate'.
Hostname and ip is forged.
my working apache config snippet:
SSLCertificateFile /etc/certs/myhost.mydomain/cert.pem
SSLCertificateKeyFile /etc/certs/myhost.mydomain/privkey.pem
SSLCertificateChainFile /etc/certs/myhost.mydomain/chain.pem
vert.x code:
val httpsOptions = HttpServerOptions()
.setPort(443)
.setSsl(true)
.setPemTrustOptions(PemTrustOptions()
.addCertPath("/etc/certs/myhost.mydomain/chain.pem"))
.setPemKeyCertOptions(PemKeyCertOptions()
.addKeyPath("/etc/certs/myhost.mydomain/privkey.pem")
.addCertPath("/etc/certs/myhost.mydomain/cert.pem")
)
vertx.createHttpServer(httpsOptions).requestHandler(router).listen()
I set vert.x logging to debug, but no error message appears.
What am I missing?
I found the solution here: https://community.letsencrypt.org/t/android-doesnt-trust-the-certificate/16498/2
I changed the cert.pem to fullchain.pem in the setPemKeyCertOptions settings, and it works.
Thank you for your effort.
The issue is in the certificate chain file chain.pem. It seems that it does not contain the full certificate chain. If you view the file it probably contains only one intermediate LE authority cert inside, i.e., Let's Encrypt Authority X3. It works with Apache because the SSLCertificateChainFile is actually deprecated and it is not being used at all.
Vert.x on the other side does use the chain.pem file. It returns only the intermediate cert and wget complains because of that. To fix the issue create a fullchain.pem file composed of both the chain.pem and the cert.pem files, e.g.,
cat cert.pem chain.pem > fullchain.pem
Then use the fullchain.pem with the PemTrustOptions configuration.
You don't need to put the LE root certificate in the fullchain.pem file, because it should already be present on both client and server side. Here's an excerpt from the TLS Protocol RFC about it.
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
My site (Apache 2.4.6 on CentOS 7) was working fine with SSL until yesterday, but now the apache service fails when I try to restart my server:
$ sudo service httpd restart
$ Enter SSL pass phrase for sitename.com:443 (RSA) : ********
$ Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
Neither of those suggested commands give much info, so by checking the ssl_error_log, I find the following relevant entries:
[ssl:debug] ssl_util_ssl.c(495): AH02412: [sitename.com:443] Cert matches for name 'sitename.com' [ ... (certificate details) ... ]
[ssl:debug] ssl_engine_init.c(984): AH02236: Configuring RSA server private key
[ssl:emerg] AH02238: Unable to configure RSA server private key
[ssl:emerg] SSL Library Error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
The last two entries indicate that the key and cert files do not match.
The configuration is specified in /etc/httpd/conf.d/sitename.conf:
SSLCertificateKeyFile /etc/pki/tls/private/sitename.com.key
SSLCertificateFile /etc/pki/tls/certs/sitename.com.crt
SSLCertificateChainFile /etc/pki/tls/certs/IntermediateCA.crt
I run the following to look at their modulus, and they do indeed match:
$ openssl x509 -noout -modulus -in /etc/pki/tls/certs/sitename.com.crt | openssl md5
$ openssl rsa -noout -modulus -in /etc/pki/tls/private/sitename.com.key | openssl md5
So it seems like everything should be working, but this is where I am stuck and cannot determine the cause of the error.
Any advice is appreciated. Thank you for your time.
I figured it out. Not sure exactly which package changed from my yum update command, but my guess is that one of them was responsible.
Anyways, I had to remove the password protection from my certificate's private key file:
$ openssl rsa -in [sitename.com.key] -out [sitename.com.key]
I have two files:
privkey.pem that starts with -----BEGIN ENCRYPTED PRIVATE KEY-----
cert.pem that starts with -----BEGIN CERTIFICATE-----
Now I should install them, but I never did this before and all related information I found (1, 2, 3) say, that I need three files:
primary.crt
private.key
intermediate.crt
The file endings are different, but from what I found my .pom files are ok, too (only the content matters and I can rename the ending).
But what files do I have now? The primary and private? And do I miss some file? Or is it possible with only the two I have?
Start with this:
SSLEngine on
SSLCertificateFile /path/to/cert.crt
SSLCertificateKeyFile /path/to/privkey.crt
This should bring the site up on SSL. While this may work with some browsers, you'd require intermediate certificates for your certificate to chain up to the Root CA to ensure your site works in all browsers.
To obtain the intermediate certificates for your site, go to What's My Chain Cert? and enter you site name. This will indicate that you are missing intermediate certificates, as expected. Use the last form field on the page to generate the intermediate certs.
Use the downloaded cert chain in the SSLCertificateChainFile directive in your Apache webserver config like this:
SSLCertificateChainFile /path/to/intermediate.crt
Once done, I suggest checking your site using an online scanner such as SSL Labs server test to ensure your certificates are properly configured and that your configuration does not expose any vulnerabilities or SSL weaknesses.
i have a Question about the certificate files and how to get a site to run on SSL.
Apache is running and SSL is built in. i am past the SSLSessionCache warning and here i am - every time the same problem - i get a mail with some files and i do not know which file is what.
I have a .key, .pem and a .p7b file and i have the VirtualHost config - how do i know which file is what?
SSLCertificateFile ?
SSLCertificateKeyFile <-- .key (i think)
SSLCertificateChainFile ?
and do i need to convert a file with openssl?
This Server is an internal Server and the certificate was issued in our company.
the certificate was issued in our company.
Any reason to not ask whoever issued the certificate the meaning of each file?
Apache requires the key and the certificate to be PEM-encoded. You can use this tool or OpenSSL to convert the . p7b to PEM.
It's hard to know what's inside the .pem and .key file without looking at the content. You can try to use the following OpenSSL commands to check which one does not fail:
# if it works, it's a CSR
openssl req -in file.pem -noout -text
# if it works, it's a certificate
openssl x509 -in file.pem -noout -text
# if it works, it's a private key
openssl rsa -in file.pem -noout -text
The chain file it's easier to spot, because it will contain several PEM-encoded certificates listed one after the other.
Depending on the Apache version, you may or may not need the SSLCertificateChainFile directive. Newer versions require you to bundle the chain and the server certificate in a single file and pass it to SSLCertificateFile. Check your Apache version and compare it with the online documentation.
Assuming it's an old version:
SSLCertificateFile points to the server certificate file
SSLCertificateChainFile points to the intermediate certificate (if it's self-signed, you don't have them)
SSLCertificateKeyFile points to the key
If it's a newer version, ignore SSLCertificateChainFile and concatenate the server plus the chain (if any) in a single file you supply to SSLCertificateFile.
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.