Wandering Thoughts archives


Allowing some Alias directives to override global Redirects in Apache

When I wrote Apache, Let's Encrypt, and site-wide reverse proxies and HTTP redirections, I confidently asserted that there was no way to override a Redirect for just some URLs, so that you could Alias the /.well-known/acme-challenge/ URL path off to somewhere while still redirecting the entire site to somewhere else. It turns out that there is a way of doing this under some circumstances, and these circumstances are useful for common Let's Encrypt configurations.

The magic trick is that if you put your Redirect directive inside a <Directory> directive, it only applies to URLs that resolve to paths inside that directory hierarchy. URLs that resolve to elsewhere, for example because they have been remapped by an Alias, are not affected and are passed through unaffected. This is extremely useful because in common configurations for Let's Encrypt clients, the challenge directory is often mapped to a common outside location in the filesystem, such as /var/run/acme/acme-challenge. So, for a virtual host you can set a DocumentRoot to some suitable spot that's not used for anything else and then wrap the site-wide redirect inside a <Directory> directive for your DocumentRoot, like this:

DocumentRoot /some/stub
<Directory /some/stub>
  Redirect permanent / https://..../

(It seems common to supply the Alias and <Directory> directives for the Let's Encrypt stuff in a general configuration snippet that's applied to all virtual hosts. Doing this globally is one reason to make them all go to a common spot in the filesystem.)

The stub DocumentRoot probably has to exist (and have permissions that allow Apache access), but it doesn't have to have anything useful in it. It's there purely to confine the Redirect away from the Alias.

(I stumbled over this trick somewhere on the Internet, but I can't find where any more.)

PS: I don't think you need to specify any AllowOverride or Options settings in your <Directory>, because they're all surplus if you're not doing anything with the stub directory tree except the Redirect. Our <Directory> sections tend to have these even when the entire site is being proxied or redirected, but that's because we're creatures of habit here.

ApacheAliasOverRedirectTrick written at 00:13:00; Add Comment


Apache, Let's Encrypt, and site-wide reverse proxies and HTTP redirections

Back in the days before Let's Encrypt, life was simple if you had an entire virtual host that wanted to be redirected somewhere (perhaps from its HTTP version to its HTTPS one) or served through a reverse proxy (which is our solution to various traditional problems with a shared webserver), since both of these were single directives in Apache. Then along came Let's Encrypt, where the simplest and easiest way to authenticate your control over a website is through their HTTP challenge, which requires specially handling random URLs under /.well-known/acme-challenge/. Now you want to reverse proxy or redirect everything but the Let's Encrypt challenge directory, and that is not entirely easy.

The easiest case is a reverse proxy, because there's a ProxyPass directive to say 'don't proxy this':

ProxyPass /.well-known/acme-challenge/ !
ProxyPassReverse /.well-known/acme-challenge/ !

(I'm not sure if you need the PPR rule.)

These come before your regular ProxyPass, because the first match wins as far as proxying goes. With reverse proxying not being done for this, your Alias directive can take over.

Redirection is unfortunately not so simple. The straightforward way to redirect an entire site is 'Redirect / ...', and once you put this in the configuration there is, as far as I can tell, no way to override it for some URLs. Redirect specifically acts before Alias and almost anything else, and can't be turned off for a subset of your URL space through a specific <Location> block.

If you only want to redirect the root of your site and have random URLs error out, you can use a restricted RedirectMatch that doesn't match the Let's Encrypt challenge path (or much of anything else):

RedirectMatch temp "^/$" https://<whatever>/

Apache doesn't appear to have any general support for negated regular expressions (unless it's hiding in the depths of PCRE), so you can't easily write a RedirectMatch directive that matches everything except the Let's Encrypt challenge path. You can do a more general version, for example one that skips all paths that start with '/.':

RedirectMatch temp "^/([^.].*|$)" https://<whatever>/$1

(As a disclaimer, I haven't tested this regular expression.)

If you want a HTTP redirection that specifically excludes only the Let's Encrypt challenge directory, then apparently you need to switch from plain Redirect and company to doing your redirection through mod_rewrite:

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/ [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=302]

(RewriteCond specifically supports negating regular expression matches.)

In theory if you're just redirecting from the HTTP to the HTTPS version of your site, you might let the Let's Encrypt challenge get redirected too. In practice I would be wary of a chicken and egg problem, where you might not be able to get Let's Encrypt to accept the redirection unless you already have a valid TLS certificate for your HTTPS site. Of course in that case you could just temporarily shut down the redirection entirely, since without a valid TLS certificate the HTTPS version is not too usable. But that requires manual action.

(Perhaps and hopefully there are other solutions that I'm missing here.)

ApacheLetsEncryptVsRedirect written at 23:06:30; Add Comment


Saying goodbye to Flash (in Firefox, and in my web experience)

Today, for no specific reason, I finally got around to removing the official Adobe-provided Linux Flash plugin packages from my office workstation. I was going to say that I did it on both my home and my office machine, but it turns out that I apparently removed it on my home machine some time ago; the flash-plugin package was only lingering on my work machine. This won't make any difference to my experience of the web in Firefox, because some time ago I disabled Flash in Firefox itself, setting the plugin to never activate. Until I walked away from Chrome, Chrome and its bundled version of Flash was what I reached for when I needed Flash.

I kept the plugin around for so long partly because for a long time, getting Flash to work was one of the painful bits of browsing the web on Linux. Adobe's Linux version of Flash was behind the times (and still is), for a long time it was 32-bit only, and over the years it required a variety of hacks to get it connected to Firefox (cf, and, and, and so on). Then, once I had Flash working, I needed more things to turn it off when I didn't want it to play. After all of this, having an officially supplied 64-bit Adobe Flash package that just worked (more or less) seemed like sort of a miracle, so I let it sit around even well after I'd stopped using it.

Now, though, the web has moved on. The last website that I cared about that used Flash moved to HTML5 video more than a year ago, and as mentioned I haven't used Flash in Firefox for far longer than that. Actively saying goodbye by removing the flash-plugin package seemed about time, and after all of the hassles Flash has put me through over the years, I'm not sad about it.

(Flash's hassles haven't just been in the plugin. I've had to use a few Flash-heavy websites over the years, including one that I at least remember as being implemented entirely as a Flash application, and the experience was generally not a positive one. I'm sure you can do equally terrible things in HTML5 with JavaScript and so on, but I think you probably have to do more work and that hopefully makes people less likely to do it.)

Flash is, unfortunately, not the last terrible thing that I sort of need in my browsers. Some of our servers have IPMI BMCs that require Java for their KVM over IP stuff, specifically Java Web Start. I actually keep around a Java 7 install just for them, although the SSL ciphers they support are getting increasingly ancient and hard to talk to with modern browsers.

(I normally say TLS instead of SSL, but these are so old that I feel I should call what they use 'SSL'.)

PS: I'm aware that there is (or was) good web content done in Flash and much of that content is now in the process of being lost, and I do think that that is sad. But for me it's kind of an abstract sadness, since I never really interacted with that corner of the web, and also I'm acclimatized to good things disappearing from the web in general.

FlashGone written at 23:53:26; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.