ssl_error_rx_record_too_long and Apache SSL [closed]

Asked 23/9, 2008 at 6:7 Answered 26/9, 2012 at 17:1

Solved apache configuration ssl webserver mod-ssl

291

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!

Belfry answered 23/9, 2008 at 6:7 Comment(10)

I'm thinking it could also be caused by a misconfigured proxy at their side of things. Any thoughts on that as well? – Belfry 23/9, 2008 at 6:40

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... – Gradatim 31/8, 2014 at 22:10

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! – Lynettalynette 10/8, 2017 at 3:15

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. – Marital 21/10, 2017 at 18:57

I could debug my certificate issues generating this message with openssl s_client -connect my-domain.tld:443 – Womankind 22/11, 2017 at 11:1

I don't have enough rep, but those who do, please vote to reopen the question! – Willhite 2/7, 2018 at 9: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. – Review 12/12, 2018 at 13:46

@Belfry "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 – Ann 22/12, 2018 at 9:32

I lost ssl keyword after port: "server { listen 443 ssl; " – Gascony 11/12, 2020 at 8: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) – Liturgical 28/12, 2020 at 14:59

191

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

Astatine answered 21/1, 2011 at 19:31 Comment(14)

Just to add to the list of things to check, after checking all of these items I had to swap my <VirtualHost default :443> to <VirtualHost fqdn :443> to get it to finally work. – Sweat 31/5, 2011 at 16:45

I had this issue on a whm/Cpanel server. I just reinstalled the ssl to fix the issue. – Phosphocreatine 22/11, 2011 at 16:12

_default_:443 worked for me. No I can go to sleep! – Smoulder 31/1, 2012 at 6: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.) – Harkins 28/10, 2013 at 19:48

Same here. default:443 worked for me. – Apia 21/1, 2014 at 9:24

Just the ports.conf change did me fine. – Demimonde 16/6, 2014 at 10:51

For SSL to work you must match the virtual host by IP address not name – Adenitis 25/5, 2015 at 17:37

@Astatine : 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. – Lamebrain 11/9, 2015 at 14:6

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. – Crispa 2/12, 2015 at 8: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! – Kone 1/4, 2016 at 12:36

In [apacheroot]/conf/extra/httpd-ssl.conf I had to correct the line: <VirtualHost default:443> to the correct SSL port I was using. – Inquiring 14/7, 2016 at 14:42

Specifying the IP address in vhost entry instead of * worked for me – Bespatter 2/3, 2017 at 21:39

Setting VirtualHost to default rather than the IP address worked for me. – Tophet 29/3, 2017 at 19:20

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 – Speckle 12/7, 2019 at 6: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.

Iridic answered 30/3, 2010 at 19:1 Comment(2)

I've used a2enmod ssl but forget to a2ensite default-ssl from default vhost conf. Thank you! – Nymphomania 24/5, 2015 at 16:18

They should really just make default-ssl enabled already in Ubuntu. – Buoyancy 4/3, 2016 at 23:55

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!

Natelson answered 20/5, 2009 at 11:13 Comment(4)

localhost:443 loads plian html, what to do? – Wentletrap 19/11, 2016 at 2:33

@Wentletrap I guess it depends on your OS defaults for the <VirtualHost> directive. Try to find out the default and adjust it accordingly and make sure SSL is enabled on that VirtualHost. – Natelson 31/5, 2017 at 15:51

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! – Indigent 22/7, 2017 at 23:2

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. – Grudging 28/5, 2018 at 13:38

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

Preponderate answered 12/5, 2009 at 17:22 Comment(1)

yes this will fix for wamp 3.2 / apache 2.4.46. thank you – Rain 11/3, 2021 at 23:0

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.

Gladden answered 18/11, 2010 at 12:36 Comment(4)

Sounds stupid but it caught me – Angling 9/8, 2012 at 3:37

use a2ensite rather than a link, this is the right way on most systems – Vindicable 30/4, 2013 at 9:39

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. – Exponent 4/8, 2015 at 6:53

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 <Whatever>.conf. Trivial, but does not cause any syntax error (never loaded after all), and irritating because an ls showed it in sites-available ... – Demetriusdemeyer 31/10, 2015 at 9:42

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.

Jennelljenner answered 16/4, 2012 at 17:12 Comment(1)

The commands 'a2ensite default-ssl' and 'a2enmodule ssl' simplify the management of the modules and sites symlinks. – Harkins 28/10, 2013 at 19:45

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.

Charlet answered 23/9, 2008 at 6:12 Comment(1)

I saw a screenshot and it's not :80 Try it for yourself: monkeyfood.cashboardapp.com – Belfry 23/9, 2008 at 6:21

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!

Radiosurgery answered 14/7, 2011 at 22:0 Comment(1)

I can confirm, that this was problem for me too... wrong IP address – Godmother 9/3, 2015 at 17:32

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...

Raquel answered 21/5, 2009 at 14:7 Comment(0)

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.

Showoff answered 30/7, 2010 at 13:21 Comment(0)

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.

Doggerel answered 16/7, 2012 at 13:1 Comment(0)

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.

Jeanajeanbaptiste answered 1/12, 2008 at 14:36 Comment(0)

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.

Aniline answered 30/6, 2009 at 14:34 Comment(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.

Accusal answered 9/9, 2009 at 9:18 Comment(1)

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. – Petition 4/5, 2018 at 12:53

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

Demos answered 26/9, 2012 at 17:1 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags