LetsEncrypt SSL Error - SSL routines:ssl3_get_record:wrong version number
Solution 1
So, looks like the handshake is okay but the cert isn't being sent.
The handshake is not ok. The Client has sent the ClientHello to start the handshake but received nothing useful back:
|- ClientHello
---
SSL handshake has read 5 bytes and written 202 bytes
---
|- nothing useful from server
I don't know what it is getting back in the 5 bytes but it does not look like TLS (too short for a TLS message). It might be some server misconfiguration which can not be seen from the part of the config you've shown. It might also be some middlebox (firewall, load balancer...) hurting the connection. It might also be that you don't connect to the expected server (i.e. example.com
does not resolve to your actual server).
I recommend that you first check on the server itself (i.e. localhost
) and if this works move further away from the server with your checks. You might also do a packet capture and have a look what you'll find in the 5 bytes received by the client.
Solution 2
Just sharing for anyone who ends up here with the same problem.
This is my experience in Ubuntu 20 with Apache
I was editing the default-ssl.conf in SITES-AVAILABLE folder but nothing happened. The above same error was repeating no matter what i did.
I copied the default-ssl.conf from sites-available into SITES-ENABLED folder without the IfModule mod_ssl.c tag and THAT SOLVED THE PROBLEM.
Hope this info helps someone.
Thanks
Solution 3
It seems apache's default *:80 HTTP handler will also listen on 443 for unmatched VirtualHost IPs including loopback.
For example, my machine has a NAT ip 192.168.32.5 and of course the 127.0.0.1 loopback. If my site conf uses <VirtualHost 192.168.32.5:443> then any requests that resolve to 127.0.0.1:443 are actually answered by the default HTTP handler...not HTTPS. Simply setting my hosts entry for the SSL hostname to 192.168.32.5 fixed the issue.
Solution 4
I had the same issue. My example.com.conf
file did have HTTPS set up properly, but my 000-default.conf
file did not. I seemed to have forgotten to include the SSL certificate and turn on the SSL engine for my 000-default.conf
, but after I fixed that, it worked perfectly.
The code I added to 000-default.conf
:
SSLEngine On
SSLCertificateFile /etc/ssl/example.com/domain.cert.pem
SSLCertificateKeyFile /etc/ssl/example.com/private.key.pem
Zakalwe
Updated on June 30, 2022Comments
-
Zakalwe over 1 year
I've managed to pull down a fresh cert from LetsEncrypt. My VirtualHost config is set up as:
<VirtualHost *:80> ServerName example.com Redirect 301 / https://example.com/ </VirtualHost> <VirtualHost *:443> Servername example.com DocumentRoot /var/www/example.com/wav ErrorLog /var/log/apache2/example.com/www/error.log SSLEngine On SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem </VirtualHost>
When trying to verify this with openssl:
openssl s_client -connect example.com -port 443
I get the following:
CONNECTED(00000003) 140229655213824:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 202 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1541086087 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
So, looks like the handshake is okay but the cert isn't being sent.
Worth pointing out that the Apache logs don't report any errors - just the usual - "starting up/shutting down" messages.
apache2ctl configtest
reports no issues. -
Patrick Mevzek about 5 yearsI agree and this is also what "ssl3_get_record:wrong version number" hints at: the client tried to parse what it received as a TLS message but the first basic parsing of getting the TLS version failed, so the input was most probably not TLS at all in fact. The length being a strong indicator also of course...
-
guru_florida over 3 yearsDepending on how your VirtualHosts IP is setup this may fail such as it did on my system. I tied my VirtualHost to an internal IP port 443, so it wasnt tied to loopback IP.
-
mwfearnley over 2 yearsThanks. Based on your advice I fixed it with:
sudo a2ensite default-ssl
;sudo systemctl reload apache2
. I didn't have to edit the .conf file. -
Chad Priddle over 2 yearsHaving the same issue on 20.04, still trying to get it to work.