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.
Related
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 have a site with two servers, apache2 and Tomcat7.
Apache2 listens to 80, while tomcat7 to 443.
Apache2 is needed to present a Wordpress blog, while Tomcat7 to serve a JSP site.
My virtualhosts scheme in Apache is like this:
http://blog.example.com ---> DefaultRoot for the blog
http://example.com ---> Redirect to https://example.com (where Tomcat listens)
Everything works fine. My original site in JSP always responds in https secure mode, while I have a working Wordpress in my "blog." subdomain.
The problem comes now that I want that blog interact with https (without any ugly 3rd port in the url if possible)
Making Apache2 to listen at 443 will obviously come to a conflict about 'port in use'.
Disabling it in Tomcat7 has no sense as somewhere it has to listen for ssl.
The question for you is: How would you face it?
I have an autoscaling application, which uses an ELB to terminate SSL, and forward 443 requests to http 80 on the instances.
This works fine, except that if I do a redirect within apache, it implicitly uses http rather than https.
for example, I have the following rewrite rule...
RewriteRule ^/v10/(.*) /v11/$1 [R]
If I do the following...
curl -v "https://[mydomain.com]/v10/somescript.js"
I get a 302 response like this...
Location: http://[mydomain.com]/v11/somescript.js
... which then breaks my application, as the browser won't load the script via http.
Of course this makes sense, since as far as apache is concerned, it is http. However aside from re-writing all my redirect rules, I'm wondering if there is some way to convince apache to implicitly generate https redirects, even though it isn't terminating the SSL?
I host 100+ websites on 2 different servers. Some of my clients recently have noticed that when they go to https://theirwebsite.com, if they DONT have SSL on their website, it redirects to the first SSL website in the apache conf file. I did some reading and discovered that SSL websites need their own IP addresses, so i switched the IP addresses of my SSL websites. However, i noticed that the problem is still happening. It's possible that there are still SSL websites that need to be removed or changed in httpd.conf, but is there a way to stop this from happening? Can i find a way to just make websites without https redirect to nothing if https is used?
it redirects to the first SSL website in the apache conf file.
This is because there are 2 sets of virtual hosts you have for apache: 1 that listens to port 80 (non-SSL) and one that listens to port 443 (SSL). Any non-SSL request gets sent to the vhosts that listens to port 80, and any SSL request gets sent to the chosts that listens to port 443. When a request is made for a host that isn't defined in any of the vhosts, it defaults to the "default" vhost, which becomes the very first one that gets defined (e.g. the first one that appears in your vhost file).
In order to prevent this, you can either have a defined SSL vhost for each of your non-SSL websites, or you can create a new "default" vhost in your SSL file that does nothing but redirect to non-SSL:
RewriteEngine On
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R]
I'm a bit out of my depth here and nothing I have found quite addresses my problem. Si any and all suggestions are most welcome.
I've got tomcat6 running on CentOS 6.5 hidden behind an apache server (v2.2.15) and I am using Apache's mod_proxy to expose the tomcat webapps, which are running on port 8080. The tomcat hosts one production application and several development applications. On the apache side, both a Drupal site and the aforementioned tomcat production application are on the same domain and, thanks to rewrite rules, all requests to this domain are changed to https. The development sites are reached via subdomains and do not get re-written as https requests.
For the most part, this arrangement works fine. But parts of the tomcat apps are AJAX (calling a Java Struts 1.2 backend). Most of those requests are handled OK. But a few AJAX requests result in redirects (i.e., forward.setRedirect(true)) and that redirect is http (I guess because the container itself is not secure). As a result, I run into cross site scripting issues. I imagine I can use CORS headers to avoid the problem. But that seems like a hack. Is there a relatively painless way I can use to have tomcat send redirects back as https without making tomcat handle ssl directly?
Cris
You could configure the RemoteIpValve in Tomcat:
Another feature of this valve is to replace the apparent scheme
(http/https) and server port with the scheme presented by a proxy or a
load balancer via a request header (e.g. "X-Forwarded-Proto").
To configure Apache to forward the original protocol in the X-Forwarded-Proto header, add a RequestHeader directive in your Apache config, e.g.:
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
...
Note that in Tomcat 7, there is also a RemoteIpFilter.
You don't need to do anything special. It already works. Make sure you set the "redirectPort" in server.xml to Apache's HTTPS port, usually 443, and add the following to your <security-constraint> sections for resources you want secured by HTTPS:
<user-data-constraint>
<description>HTTPS</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Late to the game here but others may find this-- we had a similar setup and issue where everything worked fine until the application started using ajax posts which did redirects for the response. The fix was to use mod_header in apache to rewrite redirects using "Header edit Location"
http://httpd.apache.org/docs/current/mod/mod_headers.html
Header edit Location ^http://www.example.com/ https://www.example.com/
This went unnoticed prior to the ajax redirects because the browser has no problem doing page level redirects to http (which apache would then redirect back to https). But the ajax cross-site prevention halts at the initial http missing out on that would then be redirected to https by a subsequent request.