Tag Archives: apache

Redirecting HTTPS with Let’s Encrypt and Apache

The free TLS certificate provider Let’s Encrypt automates the request-and-setup process using the ACME protocol to verify domain ownership. Software on your server creates a file in a known location, based on your request. The certificate authority checks that location, and if it finds a match to your request, it will grant the certificate. (You can also validate it using a DNS record, but not all implementations provide that. DreamHost, for instance, only uses the file-on-your-server method.)

That makes it really simple for a site that you want to run over HTTPS.

Redirected sites are trickier. If you redirect all traffic from Site A to Site B, Let’s Encrypt won’t find A’s keys on B, so it won’t issue (or renew!) the cert. You need to make an exception for that path.

On the Let’s Encrypt forums, jmorahan suggests this for Apache:


RedirectMatch 301 ^(?!/\.well-known/acme-challenge/).* https://example.com$0

That didn’t quite work for me since I wanted a bit more customization. So I used mod_rewrite instead. My rules are a little more complicated (see below), but the relevant part boils down to this:


RewriteEngine On
RewriteBase /

# Redirect all hits except for Let's Encrypt's ACME Challenge verification to example.com
RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
RewriteRule ^(.*) https://example.com/$1 [R=301,L]

These rules can go in your server config file if you run your own server, or the .htaccess for the domain if you don’t.

Continue reading

Moved to a faster server, ALMOST moved to NginX

As of last week, this site is being served to you by a shiny new SSD-backed VPS at DreamHost. I was hoping it would be running NginX as well, but try as I might, I couldn’t get WordPress in a subdirectory to play nice with NginX. Speed Force worked fine, but it’s at the top level of a site. Ramblings and Re-Reading Les Misérables aren’t.

Fortunately, the new virtual servers are faster and cheaper (newer hardware, after all), and with the rest of my sites running NginX I end up with about the same overall memory footprint for two VPSes so that I could put this back on Apache. I suppose that saved me time converting the zillions of .htaccess rules I’ve amassed over the years. And with the faster systems, they’re able to handle more complex/simultaneous actions without timing out or spiking memory.

Weird 404 logging error with PHP and mod_rewrite on DreamHost

When I started the category clean-up project a while back, I decided to start monitoring 404 errors on the blog to see if I missed any incoming links that needed to be redirected. I was surprised to find that the logs showed no 404 errors at all from within the blog structure. Images, sure, but no articles, no tags, no categories. This seemed a bit hard to believe.

I tested it by deliberately hitting a non-existent page, and was dismayed to find that Apache logged the hit as 200 (OK).

Crap! a WordPress update must have broken 404 handling! How long had this been going on? I’d better manually insert a header in the 404 page!

That seemed to work, as far as Chrome’s Developer Tools and curl -I were concerned. I didn’t have time to follow up on the logs right away, so I checked back later…and the logs still showed 200 OK, not 404.

WTF?

It turned out that, when served through WordPress, Apache was sending a 404 code to the browser but logging a 200.

Probably a plugin, right?

Not so. I installed a fresh copy of WordPress on a test site and discovered something interesting: 404 codes were logged correctly when using the default /?p=123 permalink structure, but if I changed it to anything readable like /yyyy/title or even /title, the problem recurred.

A little more investigation: I skipped WordPress entirely and just hit a PHP page that served up a 404. When I hit it directly, it logged correctly. But when I used WordPress’ mod_rewrite rules to send a hit to that page, it logged a 200.

So clearly, it was something about mod_rewrite. I don’t run my own Apache server these days (my department at work is mainly a Windows shop), but I was pretty sure it didn’t work that way back when I did.

So I did some testing of different configurations at home and on my webhost. Direct hits always logged the correct status, but with a rewrite rule, here’s what I found:

FastCGI & CGI on DreamHost show 200/404.
mod_php on home box shows 404/404.
mod_php on DreamHost shows… 200/404.

At this point I figured there was no point setting up a CGI or FastCGI-based PHP environment on my home box, because it was clearly something about Dreamhost’s Apache configuration.

It does log correctly if you use ErrorDocument directive to point 404 to a PHP script. But IMO that’s abusing the error handler mechanism to do something it wasn’t meant for. (Not that I haven’t done it myself, but only on older IIS servers where ISAPI Rewrite and URL Rewrite weren’t available.)

I’ve added a custom logging snippet to my WordPress 404 page. There are other ways I can capture the data, but that seemed like the least overhead for now.

Patch…Friday?

I suppose it’s best to release the security fixes when they’re ready, because any time you pick is going to be inconvenient for someone, but lately it seems like Friday is suddenly in style.

Last Friday saw the release of PHP 5.2.4, on the Friday before—in the US, anyway—a 3-day weekend. This morning Apache released security updates for all three supported branches of their webserver. And this evening—yes, Friday evening—WordPress 2.2.3 came out.

Which reminds me, I’m going to have to start looking at the betas for WordPress 2.3. I think it’ll be a good time for a redesign. Maybe pick a new theme and tweak that one, maybe try my hand at actually designing one. I wonder if the new tagging system can import Bunny’s Technorati Tags.

Flock and self-hosted WordPress

I reinstalled Flock today and figured out what was preventing it from talking to my self-hosted blog, K-Squared Ramblings. The site is running on a stand-alone WordPress install, and I kept getting 403 Forbidden errors. (Not that I could tell. Flock hid the error and just told me something went wrong setting up the account.)

It turned out to be a setting in mod_security, an Apache module designed to limit attacks on web applications. Part of the sample filter—one that I kept because it seemed a reasonable precaution—was to block POST requests with content types other than application/x-www-form-urlencoded or multipart/form-data. However, XMLRPC uses text/xml, which was getting blocked.

There weren’t any problems reported, and none of the false positives I saw in the logs were related to the request content-type. So by the time I tried setting up Flock, it didn’t occur to me to check the mod_security log. I just figured it was a problem with my version of WordPress and left it at that.

This time, with a newer version of Flock, I decided to investigate. I found the 403 error in the server logs, checked the error log for detail, and saw the mod_security reference. A quick check of the audit logs, and there it was.

For now, I’ve loosened the content-type requirement slightly. I’ll have to decide whether it’s worth keeping XMLRPC enabled, or whether I’m better off restoring the original rule.

SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;|^text/xml$)"

So, the moral of the story is: If you use Flock, and you can’t get it to tie into your self/third-party-hosted WordPress blog… check the ModSecurity settings.

*This was originally posted at kelson.wordpress.com, but I moved it over here after turning that site into a photo blog.