I have a web application running on Apache/Tomcat on a cloud with Linux (Digital Ocean). It had a domain name - example.com. I've encrypted both example.com and www.example.com using Let's Encrypt and now requests to https://example.com and to https://www.example.com work.
Then I wanted to redirect HTTP requests to HTTPS. But noticed that for some reason requests to http://example.com and to http://www.example.com do not work, and I'm not getting any response from my server. I tried to play with Apache configuration files of VirtualHost, but nothing worked for me so far.
Using tcpdump I see that I am receiving requests on port 80 on the server, but nothing happens except that.
What might be the reason for requests to HTTPS to work while requests to HTTP not to work?
Thanks.
Well, if someone else encounters this behavior - the reason for it was the firewall - port 443 (used by HTTPS) was open but port 80 (used for HTTP) was simply closed. Opening it solved it.
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'm trying to monitor a VHost on the local Apache instance via Monit. The same domain accepts both http and https traffic, so I wanted to monitor both.
Also, the IP that the domain resolves to goes to a server that load balances the traffic between the current Apache instance and another server running Apache. I need Monit to monitor the local instance, and I was hoping to avoid adding any records in the /etc/hosts file, so I was thinking that Monits config setting with http headers [] would suffice, and I think it is (Just monitoring localhost, but setting the headers Host to the vhost domain).
Anyways, the main problem I seem to be running into, is even though I configure Monit to monitor the host via both http and https protocols, it monitors both hosts via just http, however the port is set to 443 for the one I need using https protocol.
The Monit config file for Apache is:
check process httpd with pidfile /var/run/httpd/httpd.pid
start program = "/bin/systemctl restart httpd.service" with timeout 60 seconds
stop program = "/bin/systemctl stop httpd.service"
check host localhost with address localhost
if failed
port 80
protocol http
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if failed
port 443
protocol https
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if 5 restarts within 5 cycles
then timeout
And here's the Monit status for that check:
[root#server enabled-monitors]# monit status localhost
The Monit daemon 5.14 uptime: 14m
Remote Host 'localhost'
status Connection failed
monitoring status Monitored
port response time FAILED to [localhost]:443/ type TCPSSL/IP protocol HTTP
port response time 0.001s to [localhost]:80/ type TCP/IP protocol HTTP
data collected Tue, 26 Apr 2016 10:44:32
So it's fairly obvious to me that the https is failing because its still trying to use port HTTP, even though I have protocol https in the configuration.
Any input would be much appreciated. I have a feeling this may be a bug, and ill create an issue in the Monit Github repo, but I wan't to make sure it's not something silly that I overlooked.
Thank you!
Late reply here, but I thought I would still post for readers who stumbled upon the same issue.
The problem seems to be not with Monit using port HTTP despite check configured for HTTPS. It always reports HTTP protocol in status (a display bug).
The real issue is likely with Monit not supporting SNI for SSL, so it ignores the with http headers [Host: www.domain.com ... in your https check. Thus the check fails because Monit is actually testing https://localhost.
I've filed bug with Monit developers here.
When I setup the LBS on the aws, I set SSL offload to forward requests from port 443 on ELB to port 80 on the EC2 instances.
I am not sure this is right or not since I saw many people did that. But after I did that I got lots of errors within the browser console:
"This request has been blocked; the content must be served over HTTPS."
Should I change the forward port 80 to 443? and install ssl for each instance?
443 to 80 is correct. Your EC2 instance serves plain data, the ELB encrypts it before sending it out of AWS.
There are a few nuances to this- the server thinks it is serving plain content on 80, so if it creates URLs they will typically be http:// without some configuration. (it depends on your framework, server, etc)
The second nuance is that hardcoded URLs will break it in a similar manner. That error message has been explained in a stackoverflow question about Ajax, some form of that is causing your problem.
I followed the official docs on https setup located here: https://help.ubuntu.com/6.06/ubuntu/serverguide/C/httpd.html#https-configuration
I had to remove the +CompatEnvVars from
SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
because it said it was an invalid command or something. So having removed that and following the instructions to the nail it get the error:
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
I'm new to SSL, any advice on what's going wrong?
I've just experienced this issue. For me it appeared when some erroneous code was trying to redirect to HTTPS on port 80.
e.g.
https://example.com:80/some/page
by removing the port 80 from the url, the redirect works.
HTTPS by default runs over port 443.
I used
a2ensite default-ssl
and it worked like a charm.
If you want to force e.g. phpmyadmin to use SSL/https you will run into this problem if this link is missing.
I had that same error. I forgot to create a link from sites-enabled/000-default-ssl to the sites-available/default-ssl file.
> ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl
This seems to be the result you see from Firefox when the server is not configured properly for SSL. Chrome, BTW, just gave a generic "ssl failed" code.
What happens is that the browser sends a SSL handshake when the server is expecting an HTTP request. Server responds with a 400 code and an error message that is much bigger that the handshake message that the browser expects. Hence the FF message.
As we can see from the responses here there are many things that can break the SSL configuration but not stop the server starting or give any hints in error.log.
What I did was systematically check down all the answers until I finally found the right one, right at the bottom.
Here is what I had in the access logs:
rfulton.actrix.co.nz:80 192.168.1.3 - - [09/Oct/2016:13:39:32 +1300] "\x16\x03\x01" 400 0 "-" "-"
rfulton.actrix.co.nz:80 192.168.1.3 - - [09/Oct/2016:13:39:46 +1300] "\x16\x03\x01" 400 0 "-" "-"
rfulton.actrix.co.nz:80 192.168.1.3 - - [09/Oct/2016:13:49:13 +1300] "\x16\x03\x01" 400 0 "-" "-"
This error also occurs when you have enabled the SSL module (i.e. you have run e.g. a2enmod ssl) but not yet enabled any SSL site entries (i.e you have not run e.g. a2ensite default-ssl).
I got this error when I was trying to access a url using curl:
curl 'https://example.com:80/some/page'
The solution was to change https to http
curl 'http://example.com:80/some/page'
In my case, I needed to install mod_ssl first
yum install mod_ssl
In my case I copied a ssl config from another machine and had the wrong IP in <VirtualHost wrong.ip.addr.here:443>. Changed IP to what it should be, restarted httpd and the site loaded over SSL as expected.
Finally find out the problem:
the port 443 was listening on HTTP instead of HTTPS, changed to HTTPS solved my issue.
In my case I accidentally used SSL in the Virtualhost configuration for port 80, instead of 443.
In my case, an Ubuntu system, in ports.conf I had
NameVirtualHost *:80
NameVirtualHost 192.168.1.79
Listen 80
And then, inside , I had
NameVirtualHost *:443
Listen 443
All I had to do was remove the line NameVirtualHost 192.168.1.79. Restarted apache and problem solved.
My case is related to Greg B's -- Visual Studio creates two sites when SSL is enabled -- one for secure, and one for normal http requests. However Visual Studio chooses two ports at random, and depending on how you start the debugger you might be pointing towards the wrong page for the request type. Especially if you edit the URL but don't change the port number.
Seeing these posts jogged my memory.
I know this isn't APACHE related, but it is definitely a page that people with that error will find..
I got the same error after enabling TLSv1.2 in webmin. Right after I enabled TLSv1.2 by accident thinking it was SSLv2, I was not able to log in from https://myipaddress:10000 like I did before. I found this link http://smallbusiness.chron.com/disable-ssl-webmin-miniserv-60053.html and it helped me because I was able to access webmin config file and I was able TLSv1.2
If you are upgrading from an older version of apache2, make sure your apache sites-available conf files end in .conf and are enabled with a2ensite
Below Solution worked for me :
Type About:Config in the Address Bar and press Enter.
“This Might void your warranty!” warning will be displayed, click on I’ll be careful, I Promise button.
Type security.ssl.enable_ocsp_stapling in search box.
The value field is true, double click on it to make it false.
Now try to connect your website again.
On My side, Error if nginx.conf like
server {
listen 443;
}
curl: (35) SSL received a record that exceeded the maximum permissible length.
Solution:
server {
listen 443 ssl;
}
It's working fine after adding ssl after 443