I thought I'd followed the accepted wisdom in redirecting HTTP traffic to HTTPS, but following a DNS issue today, and having to use an IP address instead of the URL, I realise something's amiss.
Apache.conf:
<VirtualHost *:80>
ServerName 127.0.0.1
DocumentRoot /var/www/web
</VirtualHost>
<VirtualHost _default_:443>
ServerName example.com
DocumentRoot /var/www/web
SSLEngine On
SSLCertificateFile /etc/ssl/local_certs/example.com.pem
SSLCertificateKeyFile /etc/ssl/local_certs/example.com.pem.key
Header set Access-Control-Allow-Origin "*"
</VirtualHost>
<VirtualHost *:80>
ServerName example.com
Redirect permanent "/" "https://example.com/"
</VirtualHost>
Given the above I'm confused by several points:
1) If we're now using an IP address, why are any of the above ServerName specific virtual hosts serving a page? This would confuse me less if the IP address I'm using currently corresponded to the domain name (it should, but today it doesn't, DNS issue).
2) Given the IP address I'm using isn't 127.0.0.1, why am I allowed access on port 80?
To explain the 127.0.0.1 host, this is a convenience for a local apt repository. I'm aware ServerName isn't 100% secure, but that's not an immediate concern.
What happens when I browse to the site by IP:
In the first instance I am redirected to HTTPS on the same IP address, which is what I might expect. But, if I go back the address bar in the browser and remove the 's' from https, it navigates me to the page on port 80 without a redirect, and I'm free to continue browsing the site unsecured.
I should add that the out-of-the-box enabled/available site config files do still exist, but these have a document root of /var/www/html, which contains nothing other than the default apache index.html landing page, which isn't what I'm served.
Listen
andNameVirtualHost
directives?