Apache - Firefox - Chrome RewriteCond help

Question

We have a rule that rewrites all HTTP to HTTPS. That's fine.

Then we have the *:443 host that also works.

I am trying to make a rule that will change any access to the server to the FQDN.

The reason why this needs to happen is the certificate of the server is the FQDN so when a user browses to the shortened URL it flags that certificate may not be secure.

The issue I've got is I've tried various combinations of RewriteCond in Apache they all seem to work for Firefox BUT NOT in Chromium. (Not Chrome)

So for example:

<VirtualHost *:80>

RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

</VirtualHost>

<VirtualHost *:443>
ServerName example.com.web.local
SSLEngine on
SSLCertificateFile xxxx/xxxxx/xxxxxx/xxxx.crt
SSLCertificateKeyFile xxxx/xxxxx/xxxxxx/xxxx.key

RewriteEngine On
RewriteCond %{HTTP_HOST} !^example.com.web.local$ [NC]
RewriteRule ^(.*) https://example.com.web.local/$1 [L,R]

---

Actually two issues......

1. Works in Firefox not in Chromium on test.
2. Same Apache config works on test server but not on production.

As far as I can see the RewriteCond doesn't get applied in the 443 part but the 80 part is working.

---

But I think the first thing to tackle is why it works in Firefox and not Chromium.

Answer 1

why it works in Firefox and not Chromium.

You are right to be puzzled, because that doesn't make much sense, unless... you are seeing some kind of cached response in Firefox, or you have previously accepted an invalid certificate in Firefox, or there is something different with the cert authority chain in Firefox?!

The issue I've got is I've tried varying combinations of RewriteCond in Apache they all seem to work for Firefox BUT NOT in Chromium. (Not Chrome)

Again, this is "impossible". The browser "invalid certificate" security warning occurs at the very start of the request, long before mod_rewrite (RewriteCond / RewriteRule) is able to trigger a redirect. The only way this could "work" in Firefox is if Firefox did not alert you to the certificate error - which itself is a security vulnerability.

<VirtualHost *:443>
ServerName example.com.web.local
:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^example.com.web.local$ [NC]
RewriteRule ^(.*) https://example.com.web.local/$1 [L,R]

This VirtualHost container will only be triggered for requests to example.com.web.local (as defined by the ServerName directive), so these mod_rewrite directives are entirely redundant. This is why "the RewriteCond doesn't get applied in the 443 part" - the hostname is always example.com.web.local at this stage so the RewriteCond never evaluates to true.

<VirtualHost *:80>
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

You should canonicalise the host part of the URL at this stage and not use the HTTP_HOST server variable here. You are more likely to get a certificate error with this code since (for example) example.com will be redirected to example.com and www.example.com will be redirected to www.example.com (no domain canonicalisation). It is preferable to use mod_alias instead here and be explicit with the canonical host, for example:

<VirtualHost *:80>
Redirect 301 / https://example.com/

The reason why this needs to happen is the certificate of the server is the FQDN so when a user browses to the shortened URL it flags that certificate may not be secure.

The only way to resolve this when accessing https://<non-FQDN>/path/to/file (ie. HTTPS with non-canonical host) is to get a SSL certificate that covers <non-FQDN>. This is one of the key points of an SSL cert. Otherwise, if it was possible to execute code (ie. redirect) before the SSL handshake occurred then there would be a potential MITM vulnerability.