Since a week or so I'm having a SSL problem on my Nginx server intermittently.
I know there are a few other topics on this problem on stackoverflow but none of those answers seem to apply
1 Its a real problem because when I'm working on the site it just suddenly dies on me and gives me SSL error in Chrome (Version 44.0.2403.155):
SSL connection error
ERR_SSL_PROTOCOL_ERROR
And it happens on FF as well.
2 Server isn't running out of memory (no sign of OOM ran and top all seems ok as well)
3 No updates available for either Nginx (1.8.0) or OpenSSL (OpenSSL 1.0.1e 11 Feb 2013) running on Debian (7.8)
4 I do not have any special 3rd party libraries installed (just the standard nginx, mariadb, php via fpm setup no email server)
My log has these entries:
[crit] 15592#15592: *317414 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL > routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking,
Server has NTP installed to make sure server time is in sync (right?).
When I experience the problem and give it a few minutes and reload the page it works again but it keeps happening. It doesn't seem to be happening often to other people looking at my logs.
The solution I ended up with:
I had multiple server blocks using the same SSL cert for a few special subdomains and removing that solved the problem completely..
So basically it seems I can only use the CERT in one block (even though its a wildcard cert).. I think the problem is not with the cert but with Nginx accessing the CERT files or something. Using the cert or a regex for multiple subdomains did work (so having only 1 server block with the cert but then defining the domain as *.domain.com)
You could try and look into this to solve it.
https://forum.nginx.org/read.php?2,256373
Related
Ubuntu server 16.04 PHP7.4 Apache2 running wordpress Geotrust SHA256 certificate
I have started getting the following error
cURL error 60: SSL certificate problem: unable to get local issuer certificate
I have read through and tried most solutions on the many questions on here, but to no avail
The latest 2 i have tried is adding to php.ini the following 2 lines and restarted Apache and rebooted after each one to see if it solves the issue. But it does not
After downloading a fresh copy of cacert.pem The first one i tried was
curl.cainfo = "/path/to/cacert.pem"
Then i tried
openssl.cafile = "/path/to/cacert.pem"
But i still get the same error
Any assistance greatly appreciated.
Many thanks
This is likely to be a server problem ("unable to get local issuer certificate" often is):
Even when using a CA bundle to verify a server cert, you might still experience problems if your CA store does not contain the certificates for the intermediates if the server doesn't provide them.
The TLS protocol mandates that the intermediate certificates are sent in the handshake, but as browsers have ways to survive or work around such omissions, missing intermediates in TLS handshakes still happen that browser-users won't notice.
Browsers work around this problem in two ways: they cache intermediate certificates from previous transfers and some implement the TLS "AIA" extension that lets the client explicitly download such cerfificates on demand.
To figure out for sure if this is your problem, use a TLS test service like perhaps this one: https://www.ssllabs.com/ssltest/
I installed : "cpan isntall Crypt::SSLeay" So the error from "fs.cgi: ERROR 500 SSL negotiation failed:" Changed to "
failed while requesting fs.cgi: SSL negotiation failed: at /usr/local/share/perl5/LWP/Protocol/http.pm line 25 at /usr/local/share/perl5/LWP/Protocol/http.pm line 25
"
How to fix this? I searched this forum but the issue is still there. I have two servers first server is accessing the server 2, both have different ssl certificates.
Apache on CentOS 6. Please explain the solution properly.
This issue was fixed by opening port 443 on both servers.
This error occurs due to problem in SSL. Some SSL certificates won't be enabled to cover the emails. Or in your server the devocot or imap was not installed to connect SSL. I experience the same problem and its fixed by simply turning off the SSL or make it to TLS to connect the email it fixed. May be this solution help someone in future
The PHP version on my webserver was recently updated. Now I notice that when downloading external https URLs with Curl, for one specific server it fails, giving me this error:
SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Downloading https stuff from this server though Curl worked fine before.
Now the strange this is: it seems an SSL3 error, but as I understood from other cases regarding this error (also here on SO) it's due to SSL3 no longer being supported by updated versions of PHP or Curl. And rightly so, since SSL3 is insecure.
However, this particular webserver uses TLS1.2, and by no means SSL3.
So if my Curl is not using SSL3, and neither is the webserver, why am I still getting SSL3 related errors?
I already tried setting CURLOPT_SSLVERSION to 4, 5 or 6, and setting CURLOPT_SSL_CIPHER_LIST to TLSv1, all to no avail, error keeps coming up.
Although this error message looks like it is using SSL 3.0 it is probably not. Since TLS1.0 is practically SSL3.1 etc you will find lots of functions and error messages having the SSLv3 string within the TLS code path in OpenSSL. The problem with this specific server is probably something else and one would need to know the server hostname and your installed version of OpenSSL to find out more about the problem.
EDIT: Based on the comment the version of OpenSSL used with curl is 0.9.8b. Since the server can only do TLS 1.2 the handshake will fail, since TLS 1.2 is only supported since OpenSSL 1.0.1. Apart from that 0.9.8b is years out of support and has several security problems which got fixed in later versions.
I switched with my Domain to Cloudflare and now I'm trying to use CloudFlare's SSL Feature.
I already own a SSL cert from StartSSL so I would be possible to set the settings to 'Full (Strict)' but I don't want to so I turned it to 'Full'.
Now I'm getting 525 Errors, after a 'Retry for a live Version' everything is okay.
But I'm getting this Error everytime.
Has anyone an idea ?
Thank you
Picture of my Error
Change Cloudflare SSL/TLS encryption mode in to Flexible. it worked for me.
A 525 error indicates that CloudFlare was unable to contact your origin server and create a SSL connection with it.
This can be due to:
Your servers not having matching or compatible SSL Ciphers
Your website may not have a certificate installed properly
Your website may not have a dedicated IP OR is not configured to use SNI
Attempt to contact your hosting provider for assistance to ensure that your SSL certificate is setup correctly. If you are using a control panel, a quick google search can help you find a install guide for that said control panel.
Visit SSL/TLS tab in Cloudflare. Then:
Switch Your SSL/TLS encryption mode to Flexible.
Make sure to switch On "Always Use HTTPS" under "Edge Certificate" tab.
This will transfer all your request from Http to Https automatically. And if you'll implement custom SSL certificate on your hosting server then this 525 error will automatically disappear without changing anything on Cloudflare.
Got the same problem a few days ago.
Our DevOps contacted support and found out that Cloudflare changed certificate type or smth in that way. Asked to return everything back.
That helped.
I went through the same problem today and found that (at least in my case) it was the lack of TLS v1.3
I had just made a server using nginx + php-fpm and a self signed ssl to use below CloudFlare proxy.
When I switched from the production server to this new one, it gave error 525.
I gave the command: curl -I https://your_server_public_ip/ and it returned the error:
error: 1408F10B: SSL routines: ssl3_get_record: wrong version number
This error is described in the CloudFlare community at:
https://community.cloudflare.com/t/community-tip-fixing-error-525-ssl-handshake-failed/44256
There they advise turning off TLS v1.3 on the CloudFlare panel, but I decided to try installing it.
Using nginx is so easy that I don’t know why to have it shut down.
Only add TLSv1.3 like this-> ssl_protocols TLSv1.2 TLSv1.3; in your nginx/snippets/ssl-params.conf file (default Ubuntu 20 and 18) that will work and you still use the latest and most secure protocols.
My Nginx server has an SSL certificate that looks really good and works in most browsers perfectly. The server is https://live.evmote.com . You can "hit" the server by going to https://live.evmote.com/primus .
The SSL Cert check is here: https://www.ssllabs.com/ssltest/analyze.html?d=live.evmote.com
So far, so good. The problem is specifically on the Tesla Model S browser (the in-car browser). It gives a "Bad certificate" error. The Tesla browser is notoriously bad and has incomplete support. There's no way to view the cert chain or debug the problem from the Tesla. It's more like an appliance than a computer.
Here's the SSL support from within the Tesla:
http://i.imgur.com/EbIrClM.jpg
On the Nginx server, I'm getting this error in the log:
SSL3_GET_CLIENT_HELLO:no shared cipher
Now, clearly from the Tesla SSL report and the server report, there are shared ciphers. I would expect that they would handshake on this one:
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
I'm not sure how to troubleshoot from here.
Thanks,
Ryan
The error message might be misleading. What's definitely a problem is that the browser does not support SNI, but your web site requires it. At least it only serves the valid certificate (for live.evmote.com) for SNI capable browsers, all the others get a self-signed wildcard certificate which will not be accepted by a browser doing proper certificate validation.
We've hit similar problem from the Java client. The root cause was explicitly set protocols in SSL context (io.netty.handler.ssl.SslContext):
val ctx = io.netty.handler.ssl.SslContextBuilder.forClient()
...
.protocols("SSLv2Hello,TLSv1.2,TLSv1.3".split(","))
.build()
And precisely SSLv2Hello, that should be neither declared nor used here.
Unfortunately, we can't control all our clients. So further investigation showed this problem has appeared after OpenSSL upgrade to 1.1.*.
Once we downgraded OpenSSL to 1.0.* it do the trick. Nginx 1.18.0 + OpenSSL 1.0.2u could handle handshakes with SSLv2Hello without errors and with the highest protocol possible.