285

I've got a customer trying to access one of my sites, and they keep getting this error > ssl_error_rx_record_too_long

They're getting this error on all browsers, all platforms. I can't reproduce the problem at all.

My server and myself are located in the USA, the customer is located in India.

I googled on the problem, and the main source seems to be that the SSL port is speaking in HTTP. I checked my server, and this is not happening. I tried the solution mentioned here, but the customer has stated it did not fix the issue.

Can anyone tell me how I can fix this, or how I can reproduce this???

THE SOLUTION

Turns out the customer had a misconfigured local proxy!

starball
  • 20,030
  • 7
  • 43
  • 238
Subimage
  • 4,393
  • 3
  • 24
  • 18
  • 49
    Since it was closed as off topic but seems to be a very valuable question (ranks very high in Google for this error message) maybe it should be moved to ServerFault? It's a 6-year old question so perhaps SF wasn't available when the question was asked initially... – kdmurray Aug 31 '14 at 22:10
  • I'm thinking it could also be caused by a misconfigured proxy at their side of things. Any thoughts on that as well? – Subimage Sep 23 '08 at 06:40
  • Interesting that there are 5+ solutions, all different, to the same error message. Strange that we all get the cryptic and unhelpful "*record_too_long*" for different reasons! – Demis Aug 10 '17 at 03:15
  • 36
    This is the first web search result for SSL_ERROR_RX_RECORD_TOO_LONG. It has 32 favorites, 193 upvotes, multiple much-upvoted answers... and it's closed as off topic according to a person who knows better than the rest of us that this question has no right to exist. – Val Kornea Oct 21 '17 at 18:57
  • 4
    I could debug my certificate issues generating this message with `openssl s_client -connect my-domain.tld:443` – azmeuk Nov 22 '17 at 11:01
  • I don't have enough rep, but those who do, please vote to reopen the question! – dr_ Jul 02 '18 at 09:44
  • I have found one site that was failing to allow a download due to this error - disabling the "HTTP Everywhere" add-on was the (temporary) solution. – Jool Dec 12 '18 at 13:46
  • 8
    @Subimage "THE SOLUTION Turns out the customer had a misconfigured local proxy!" Please explain what this means. You could be more specific; it's frustrating to know you have the solution but you don't explicitly spell it out – ptrcao Dec 22 '18 at 09:32
  • I lost ssl keyword after port: "server { listen 443 ssl; " – Daniil Iaitskov Dec 11 '20 at 08:30
  • i voted for reopen maybe there should be a discussion on meta to consider reopening questions with more than 100 k views (or some other reasonably high value of views) – Wolfgang Fahl Dec 28 '20 at 14:59

15 Answers15

188

The link mentioned by Subimage was right on the money for me. It suggested changing the virtual host tag, ie, from <VirtualHost myserver.example.com:443> to <VirtualHost _default_:443>

Error code: ssl_error_rx_record_too_long

This usually means the implementation of SSL on your server is not correct. The error is usually caused by a server side problem which the server administrator will need to investigate.

Below are some things we recommend trying.

  • Ensure that port 443 is open and enabled on your server. This is the standard port for https communications.

  • If SSL is using a non-standard port then FireFox 3 can sometimes give this error. Ensure SSL is running on port 443.

  • If using Apache2 check that you are using port 443 for SSL. This can be done by setting the ports.conf file as follows

    Listen 80
Listen 443 https

  • Make sure you do not have more than one SSL certificate sharing the same IP. Please ensure that all SSL certificates utilise their own dedicated IP.

  • If using Apache2 check your vhost config. Some users have reported changing <VirtualHost> to _default_ resolved the error.

That fixed my problem. It's rare that I google an error message and get the first hit with the right answer! :-)

In addition to the above, these are some other solutions that other folks have found were causing the issue:

  • Make sure that your SSL certificate is not expired

  • Try to specify the Cipher:

    SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:+SSLv3

Randall
  • 2,859
  • 1
  • 21
  • 24
  • 6
    Just to add to the list of things to check, after checking all of these items I had to swap my to to get it to finally work. – JimP May 31 '11 at 16:45
  • 2
    I had this issue on a whm/Cpanel server. I just reinstalled the ssl to fix the issue. – Mike D Nov 22 '11 at 16:12
  • 17
    `_default_:443` worked for me. No I can go to sleep! – Garfonzo Jan 31 '12 at 06:34
  • Another thing to check, you may have SSL on default, but if you have a new virthost with this problem, you may not have provided the SSL configuration yet even though the port is open. (aka, oops, I missed a step.) – Josiah Oct 28 '13 at 19:48
  • Same here. _default_:443 worked for me. – miCRoSCoPiC_eaRthLinG Jan 21 '14 at 09:24
  • Just the ports.conf change did me fine. – Zayne S Halsall Jun 16 '14 at 10:51
  • For SSL to work you must match the virtual host by IP address not name – Eugen Konkov May 25 '15 at 17:37
  • 1
    @Randall : It may seems stupid, but also make sure your "[website_domain].conf" is read by Apache. (write garbage in if and make sure apache complains on start). I had this error just because I forgot the .conf at the end of the symlink. Therefore Apache did not use the conf and it was sending plain HTML (error page) instead of requiring SSL authentification. – bokan Sep 11 '15 at 14:06
  • 1
    Also, check and make certain you don't have other VirtualHost conf files listening to port 443 with improper settings. One bad conf file can bring all the SSL sites down. – Nostalg.io Dec 02 '15 at 08:56
  • had to use `_default_:443` to fix it, as DNS name had both IPv4 and IPv6 addresses, so just `192.168.66.99:443` wasn't enough! – Matija Nalis Apr 01 '16 at 12:36
  • In [apacheroot]/conf/extra/httpd-ssl.conf I had to correct the line: to the correct SSL port I was using. – Jan Jul 14 '16 at 14:42
  • Specifying the IP address in vhost entry instead of * worked for me – Steven H Mar 02 '17 at 21:39
  • Setting VirtualHost to _default_ rather than the IP address worked for me. – Christopher Will Mar 29 '17 at 19:20
  • 1
    In my case, the order in which conf files were executed, was wrong. The default vhost needs to execute 1st and then the custom ones – Monish Sen Jul 12 '19 at 06:56
133

The solution for me was that default-ssl was not enabled in apache 2.... just putting SSLEngine On

I had to execute a2ensite default-ssl and everything worked.

Ben
  • 60,438
  • 111
  • 314
  • 488
34

In my case I had to change the <VirtualHost *> back to <VirtualHost *:80> (which is the default on Ubuntu). Otherwise, the port 443 wasn't using SSL and was sending plain HTML back to the browser.

You can check whether this is your case quite easily: just connect to your server http://www.example.com:443. If you see plain HTML, your Apache is not using SSL on port 443 at all, most probably due to a VirtualHost misconfiguration.

Cheers!

alexm
  • 694
  • 8
  • 8
  • 1
    http://localhost:443 loads plian html, what to do? – niran Nov 19 '16 at 02:33
  • @niran I guess it depends on your OS defaults for the `` directive. Try to find out the default and adjust it accordingly and make sure SSL is enabled on that VirtualHost. – alexm May 31 '17 at 15:51
  • 2
    Had this problem with a vhost because 000-default.conf had an unused :443 section without SSLEngine. The Apache log showed this, which got me on the right track: `AH01916: Init: (myhost.example.com:443) You configured HTTP(80) on the standard HTTPS(443) port!` – mivk Jul 22 '17 at 23:02
  • My problem was I had not run "sudo a2ensite default-ssl.conf". The ssl conf was simply not in the sites-enabled directory, only in sites-available. – Paintoshi May 28 '18 at 13:38
22

In my case I had forgot to set SSLEngine On in the configuration. Like so,

<VirtualHost _default_:443>
  SSLEngine On
  ...
</VirtualHost>

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslengine

Christian Davén
  • 16,713
  • 12
  • 64
  • 77
12

If you have the error after setup a new https vhost and the config seems to be right, remember to link in sites-enabled too.

drillingman
  • 249
  • 3
  • 6
  • 2
    Sounds stupid but it caught me – Alexei Tenitski Aug 09 '12 at 03:37
  • 2
    use a2ensite rather than a link, this is the right way on most systems – AsTeR Apr 30 '13 at 09:39
  • 1
    Also, check for the rule at apache2.conf (Ubuntu): IncludeOptional sites-enabled/*.conf . Be sure your links end in ".conf" or change that rule to include all files. – lepe Aug 04 '15 at 06:53
  • 1
    i created the site config with correct syntax and linked it to sites-available. The Problem was: the name of my config did not end with ".conf", as such it was never loaded and i got above error. The Configs in my case were loaded with the directive "IncludeOptional sites-enabled/*.conf" therefore the config also has to be name .conf. Trivial, but does not cause any syntax error (never loaded after all), and irritating because an ls showed it in sites-available ... – roland.minner Oct 31 '15 at 09:42
8

Old question, but first result in Google for me, so here's what I had to do.

Ubuntu 12.04 Desktop with Apache installed

All the configuration and mod_ssl was installed when I installed Apache, but it just wasn't linked in the right spots yet. Note: all paths below are relative to /etc/apache2/

mod_ssl is stored in ./mods-available, and the SSL site configuration is in ./sites-available, you just have to link these to their correct places in ./mods-enabled and ./sites-enabled

cd /etc/apache2
cd ./mods-enabled
sudo ln -s ../mods-available/ssl.* ./
cd ../sites-enabled
sudo ln -s ../sites-available/default-ssl ./

Restart Apache and it should work. I was trying to access https://localhost, so your results may vary for external access, but this worked for me.

Tarka
  • 4,041
  • 2
  • 22
  • 33
  • 10
    The commands 'a2ensite default-ssl' and 'a2enmodule ssl' simplify the management of the modules and sites symlinks. – Josiah Oct 28 '13 at 19:45
5

Ask the user for the exact URL they're using in their browser. If they're entering https://your.site:80, they may receive the ssl_error_rx_record_too_long error.

dan-manges
  • 5,097
  • 4
  • 19
  • 16
4

In my case, I had the wrong IP Address in the virtual host file. The listen was 443, and the stanza was <VirtualHost 192.168.0.1:443> but the server did not have the 192.168.0.1 address!

fimbulvetr
  • 742
  • 7
  • 8
2

You might also try fixing the hosts file.

Keep the vhost file with the fully qualified domain and add the hostname in the hosts file /etc/hosts (debian)

ip.ip.ip.ip name name.domain.com

After restarting apache2, the error should be gone.

Anna B
  • 5,997
  • 5
  • 40
  • 52
2

Please see this link.

I looked in all my apache log files until I found the actual error (I had changed the <VirtualHost> from _default_ to my fqdn). When I fixed this error, everything worked fine.

Gottlieb Notschnabel
  • 9,408
  • 18
  • 74
  • 116
rogovsky
  • 29
  • 1
2

My problem was due to a LOW MTU over a VPN connection.

netsh interface ipv4 show inter

Idx  Met   MTU   State        Name
---  ---  -----  -----------  -------------------
  1 4275 4294967295  connected    Loopback Pseudo-Interface 1
 10 4250   **1300**  connected    Wireless Network Connection
 31   25   1400  connected    Remote Access to XYZ Network

Fix: netsh interface ipv4 set interface "Wireless Network Connection" mtu=1400

It may be an issue over a non-VPN connection also...

1

I had a messed up virtual host config. Remember you need one virtual host without SSL for port 80, and another one with SSL for port 443. You cannot have both in one virtual host, as the webmin-generated config tried to do.

1

In my case the problem was that https was unable to start correctly because Listen 443 was in "IfDefine SSL" derective, but my apache didnt start with -DSSL option. The fix was to change my apachectl script in:

$HTTPD -k $ARGV

to:

$HTTPD -k $ARGV -DSSL

Hope that helps somebody.

Jeff Atwood
  • 63,320
  • 48
  • 150
  • 153
0

For me the solution was that my ddclient was not cronning properly...

Anon
  • 151
  • 1
  • 3
0

I had the same problem in some browser to access to my SSL site. I have found that I had to give to fireFox the right proxy (FireFox was accessing directly to internet).

Depending of the lan configuration (Tunneling, filtering, proxy redirection), the "direct access to internet" mode for FireFox throws this error.

Pierre-Gilles Levallois
  • 4,161
  • 4
  • 28
  • 37
  • Some proxies return an HTTP error response to a HTTPS request it's not expecting (e.g. if you went through the wrong proxy, or the proxy is misconfigured). This can be really hard to diagnose because browsers will just reject the whole conversation and throw up an error, rather than showing you the proxy's error message. Wireshark does the job though. Just ran into this myself. – Lightness Races in Orbit May 04 '18 at 12:53