Zakalwe
Zakalwe

Reputation: 1622

LetsEncrypt SSL Error - SSL routines:ssl3_get_record:wrong version number

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.

Upvotes: 12

Views: 64064

Answers (7)

Chris
Chris

Reputation: 6193

We had the problem that our HTTPS-port was serving unencrypted HTTP.

The reason was that we had two VirtualHosts on the same port and one was configured to use SSLEngine on and the other one not.

Deactivating the unencrypted site fixed the problem. Using SSLEngine on on both VirtualHosts would also fix it.

Also, we needed a proper service restart to get out of that problem. A reload had not fixed the problem, although the config was correct at that time.

Upvotes: 1

Connor Irwin
Connor Irwin

Reputation: 77

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

Upvotes: 1

guru_florida
guru_florida

Reputation: 656

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.

Upvotes: 1

Saravanakumar Thevar
Saravanakumar Thevar

Reputation: 71

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

Upvotes: 3

bwolmarans
bwolmarans

Reputation: 31

set your file types for ssl as well, this is confirmed working See the FilesMatch section? If that is missing, you will see this error.

SSLEngine on
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
SSLCertificateFile /etc/letsencrypt/live/mysite.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mysite.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
#SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
#SSLCipherSuite "AES256-SHA"
SSLCipherSuite HIGH:!aNULL:!MD5

Upvotes: 0

Ryan Ye
Ryan Ye

Reputation: 131

I got the same error with you. suggest you test your https connection on local, add your domain name to /etc/hosts, ex: 127.0.0.1 yourdomain.com in order to keep packet not going out.

then using "links" to test the https connection in local environment, if no problem, then it's caused by ISP firewall issue or setting, I finally found local https connection ok and throw the problem to ISP to solve this problem finally, good luck!

Upvotes: 0

Steffen Ullrich
Steffen Ullrich

Reputation: 123541

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.

Upvotes: 4

Related Questions