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.
Related
Problem Background:
As part of the Computer Networking course assignment, I have been given task of implementing a Proxy Server ( using python socket and ssl module ) that handles https communications between the browser and the origin server (The real server that my browser wants to talk to).
What I have done so far:
I have implemented the above requirement using ssl sockets and also generated self-signed 'cert.pem' 'key.pem' files.
What I need to do:
Now I just need to tell my browser (chrome 89 on kubuntu 20.04) to accept this self-signed certificate and then test the working of my proxy server.
Reading from this stackoverflow question, I can see that I have to:
(1) become my own CA (2) then sign my SSL certificate as a CA. (3) Then import the CA certificate (not the SSL certificate, which goes onto my server) into Chrome.
My confusion/question:
So if I do this, when eventually I am done with this assignment, how do I reverse all these steps to get my browser in the previous state before I had made all these changes. Also, how to reverse the "become your own CA" and also delete the SSL certificates signed by my CA.
Basically, I want my system to return to the previous state it was before I would have made all these changes.
UPDATE:
I have done the previously outlined steps but now I get an error.
Here is a snippet of my code:
serv_socket = socket(AF_INET, SOCK_STREAM)
serv_socket.bind(('', serv_port))
serv_socket.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context = context.load_cert_chain('cert.pem', 'key.pem')
context.set_ciphers('EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH')
serv_socket.listen(10)
socket_to_browser, addr = serv_socket.accept()
conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True)
At the last line conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True) an exception is thrown: [SSL: HTTPS_PROXY_REQUEST] https proxy request (_ssl.c:1123)
What am I doing wrong ?
As glamorous as "becoming your own CA" sounds, with openssl it basically comes down to creating a self-signed certificate, and then creating a directory where some CA-specific configuration will be stored (I don't fully remember the specifics, but I think it was just some files related to CNs and serial numbers) so basically reversing the "become your own CA" step is something as mundane as deleting this directory along with the private key and self-signed certificate you were using for the CA. That's it, the CA is no more.
And for chrome returning to the previous state, you would just go the the CA list where you added the CA certificate, select it and delete it. Chrome will stop accepting certificates signed by your CA.
Regarding your new problem... In my opinion, you have developed some kind of reverse proxy (meaning that you expect normal HTTPS requests that you then redirect to the real server) but you have configured Chrome to use it as a forward proxy. In this case, Chrome does not send it a normal HTTPS request, it sends a special non-encrypted CONNECT command and only after receiving the non-encrypted response, it negotiates the TLS connection. That's why openssl says "https proxy request" because it has detected a "https proxy request" (a CONNECT command) instead of the normal TLS negotiation.
You can take a look at How can a Python proxy server (using SSL socket) pretend to be an HTTPS server and specify my own keys to get decrypted data?
It's python, but I think that you'll get the idea
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/
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.
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