Question posted in
Some documentation to get you started can be found here.

LetsEncrypt SSL Error – SSL routines:ssl3_get_record:wrong version number – Apache

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.

Tags:

7

Answers


  1. 0

    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.

    Login or Signup to reply.
  2. 0

    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!

    Login or Signup to reply.
  3. 0

    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
    Login or Signup to reply.
  4. 0

    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

    Login or Signup to reply.
  5. 0

    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.

    Login or Signup to reply.
  6. 0

    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
    Login or Signup to reply.
  7. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search