: Apache - Firefox - Chrome RewriteCond help 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

@Jamie184

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 ^(.*) example.com.web.local/ [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 ^(.*)$ %{HTTP_HOST} [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 example.com will be redirected to 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 / 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 <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.

Vote Up Vote Down