We have Nginx running and multiple (around 80) server blocks/websites configured with both HTTPS and HTTP. Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working. On checking the access.log, I found below logs
[23/Apr/2019:15:06:02 +0530] "\x16\x03\x01\x02\x00\x01\x00\x01\xFC\x03\x039\xAD$\xB4\xBB\x94\x98\xB8Q9\x84\xE4C\xB7\x98Z8\x9E#\x8E\xF8\xD79Jl\xA3\xAEY\xB9\xDA\x1A> \x04\xD7\x1B\xE7\x1Ch\xC3`\x81?g}\xE1y\x8D\x8E\x07\xDA;\x0F\x9D\x0B\xFF\xA2p\x0F\xB5&\xDFa\xF0\xF9\x00\x22ZZ\x13\x01\x13\x02\x13\x03\xC0+\xC0/\xC0,\xC00\xCC\xA9\xCC\xA8\xC0\x13\xC0\x14\x00\x9C\x00\x9D\x00/\x005\x00" 400 182 "-" "-"
This strange http request is getting printed for HTTPS websites hit.
What can be the possible reason for this? Is there any limit on number of server blocks files in /sites-available or /sites-enabled?
Thanks!
... "\x16\x03\x01...\x03\x03...
...This strange http request...
This is an attempt to do HTTPS on a port where you have configured HTTP. What you see is the byte sequence of a TLS 1.2 ClientHello, i.e. the start of a TLS handshake.
Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working.
Likely there happened a misconfiguration while adding the new domain which caused port 443 to be plain HTTP and no longer HTTPS. Any attempt to speak HTTPS to this port (i.e. anything https://example.com since this uses 443 by default) will cause the strange entries in the access log file. Please look at the error log for hints what might have gone wrong with your configuration.
I use a Bitnami MEAN installation (https://bitnami.com/stack/mean) v 3.2.11 on EC2. I didn't do any extra modifications of the apache2 setup except for the rerouting the port where my app runs to port 80, like this
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
Now my app is available fine on :80 port via http:// but I can't make it run via https://. But access via https is what I wanted to achieve. I could not figure the right step by step guide on how to create or enable SSL. All Bitnami docs sound like it's assumed to be working already.
As far as I understood from - https://docs.bitnami.com/aws/components/apache/#https-port the basic certificate is already included into the setup so you can make use of that one without creating your own. The only thing you need is to enable it - That may be wrong assumption, let me know.
Also here on bitnami support it says
Apache waits for HTTPS requests on port 443. Change that by editing
the /opt/bitnami/apache2/conf/bitnami/bitnami.conf file and modifying
the value specified in the Port directive. For example:
Listen 8443
Does that mean that I need to reroute my :5000 port to :8443 ??
I've also found this question - Installing SSL on AWS EC2 Bitnami Mean Stack that didn't recieve a proper answer for more than a year.
Does that mean that I need to reroute my :5000 port to :8443 ??
No, you don't need to redirect that. Your problem is that you're proxy-passing every request from port 80 to 5000 (where your app runs) but when using HTTPS your requests use the port 443. Those request are not being proxy-passed to port 5000 and, therefore, your app doesn't receive them.
What Apache configuration file did you modify including those lines? You need to be sure that both the VirtualHosts for port 80 and the one for port 443 include the ProxyPass redirections. For example, if you edited the file /opt/bitnami/apache2/conf/bitnami/bitnami.conf, ensure you add it in the Virtualhosts <VirtualHost _default_:80> and <VirtualHost _default_:443>
As far as I understood from - https://docs.bitnami.com/aws/components/apache/#https-port the basic certificate is already included into the setup so you can make use of that one without creating your own.
Yes, the Bitnami Stack includes a dummy certificate. However, it's recommended to create your own one since the browsers won't recognize it as a valid one since it's self-signed. You can find more information in the link below:
https://docs.bitnami.com/aws/components/apache/#how-to-create-an-ssl-certificate
I have a wildcard SSL certificate on my apache server. It works perfectly with my domain, but the mistake is that it works with all the domains on my apache server ! And I don't want it, when I go on https://www.mywebsitewithouthttps.com, firefox tell me that the page is not secure because the certificate is for www.mydomainwithhttps.com. If I add an exception for this SSL error on my browser, it is not "mywebsitewithouthttps.com" that is display but "mydomainwithhttps.com" (on this URL : https://www.mywebsitewithouthttps.com) !
I don't want my certificate to work for all the other domains ! It's a big problem because Google is crawling and indexing all my other domains on HTTPS with the content of mydomainwithhttps.com :-(
This my virtualhost for SSL :
NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.mydomainwithhttps.com
DocumentRoot "/home/mydomainwithhttps/www"
suPHP_Engine On
suPHP_AddHandler x-httpd-php
suPHP_UserGroup mydomainwithhttps users
AddHandler x-httpd-php .php
SSLEngine on
SSLCertificateFile /certificates/ssl_certificate.crt
SSLCertificateKeyFile /certificates/www.mydomainwithhttps.com.key
SSLCACertificateFile /certificates/IntermediateCA.crt
</VirtualHost>
If you make a HTTPS request the client will establish a TCP connection to the relevant IP and port (usually 443) at the server. If the connection succeeded it will start the TLS handshake and during the TLS handshake it will get the certificate for validation.
If you have multiple servers at the same IP address and port they all share the same TCP listener. Since the TCP connection attempt has no information about the targets server name but only has the targets IP address and port the listener will accept all connection attempts, even if the (yet unknown) target hostname has no HTTPS configured.
Modern clients then send the target hostname inside the TLS handshake and only then the server knows what the client wants. If it has HTTPS configured for the requested name the server can send the appropriate certificate. If HTTPS is not configured for this name the server will either send a default certificate or close the connection (maybe send a TLS alert when closing).
In summary this leaves you with the following options:
Use a different IP address for HTTPS sites and non-HTTPS sites. This way the TCP connection will already fail because the server is not listening for connections on this IP:port.
Configure your server to return an error when the client requests a hostname for which no HTTPS is configured. This way the client will probably get some strange error message about HTTPS problem in the browser. I'm not sure but maybe you can setup Apache this way when using the SSLStrictSNIVHostCheck on option. If this option does not help then apache might not support this kind of setup.
Configure your server to use a default certificate (usually the first configured certificate) whenever the name does not match or the client does not support SNI. The client will get a certificate mismatch warning in the browser. This is the setup you currently have.
Setup HTTPS properly for all domains either by having separate certificates or by including them all into a single certificate.
Thus to make sure that the bots don't assume that your site can do HTTPS you need to go with option 1 or 2. Please note also that in all of these cases you expect the bots to support SNI, which not all do. Therefore for best compatibility you would need to use a separate IP address for each HTTPS site.
You can configure the multi domain with SSL and with different certificate on both UBUNTU and RHEL by following multi donain with ssl
The problem is that Apache will try to find config for https://www.mywebsitewithouthttps.com/ and when it doesn't, it will default back to the first https config (the one for mydomainwithhttps).
This will show a cert error but, as you've experienced, if you click through, you see the wrong site.
I cannot however understand Google crawling and indexing the site. I would have thought it would have stopped when it saw the cert error? I'd be very surprised if that is not the case but if it's not you can put a rewrite rule on for those hostname a to redirect back to http.
There's only 2 ways around this:
Get certs for the other domains so you can connect via https. You can still redirect back to http if you really want.
Separate out the servers with https to a different server (or a different IP on the same server and set up Apache config to listen on port 443 on https IP address only).
That's just the way Apache (and most - if not all - other webservers) work.
I have successfully added SSL certificate to my url. now url is "https://puinex5xgm-l1". Its working fine on browser. but whenever I try to add port to this ulr "https://puinex5xgm-l1:90/" its giving me "SSL connection error ERR_SSL_PROTOCOL_ERROR". My apache server is running on port 90.
While creating certificate I have used domain name as "puinex5xgm-l1".
Please help.
ERR_SSL_PROTOCOL_ERROR is not related to the certificate. My guess is that you don't have https on port 90 enabled but instead plain http, which then will cause such an error.
I have found the solution.
I have made changes in "httpd-ssl.conf" file. Here, I have used "VirtualHost default:90" instead of "VirtualHost default:443".
Now Apache server listening my port.
Its working fine now.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
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!
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
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.
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!
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
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.
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.
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.
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!
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...
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.
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.
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.
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.
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.
For me the solution was that my ddclient was not cronning properly...