Category Archives: IIS

UrlRewrite: SSL for Free Manual Verification Rule

2017 has really been the year when SSL implementation on websites has taken off. Google’s near requirement of them for SEO has forced many websites to implement some form of SSL certificate. For small personal or business, the biggest blocker for SSL hasn’t been the actual installation but the cost. Although prices have fallen, some website owners still resist forking out £30 for an SSL certificate especially if their site doesn’t actually process sensitive data.

Thankfully, SSL For Free has stepped into the fray providing free SSL certificates from the LetsEncrypt Certificate Authority.

To obtain a certificate from SSL for Free, it is necessary to verify your domain. You can do this either via FTP, DNS or manual verification. I often go the manual verification route as I find it to be faster and simpler to accomplish.

With manual verification, it necessary to download a small file to your website which SSLforFree looks for. If your site is already running in SSL and/or only accepts SSL requests, manual verification will fail as it would appear that SSLForFree only checks for the file via HTTP.

To avoid messing with IIS configuration, the simplest away around this is to use a UrlRewrite rule that acts as a pass through for verification requests:

1
2
3
4
5
6
7
<rule name="SSLForFree Pass Through" stopProcessing="true">
  <conditions logicalGrouping="MatchAll">
    <add input="{URL}" matchType="pattern" pattern="^\.well-known/acme-challenge/(.*)" ignoreCase="true" />
    <condition scope="serverVariable" index="SERVER_NAME" test="matchRegex" value="localhost|127\.0\.0\.1|::1" negate="true" />
  </conditions>
  <action type="redirect" redirectType="307" url="http://{HTTP_HOST}{HTTP_X_ORIGINAL_URL}" appendQueryString="true" />
</rule>

If you are using this rule in conjunction with an HTTP to HTTPS rule (see earlier post), it should be placed before any such rule as manual verification is done through a HTTP request.

Automated Implemention
As side note, users of the SolidCP hosting control panel – as Calzada Media are – can install LetsEncrypt certificates through the hosting control panel. Once issued, SolidCP should automatically renew the certificates every 2 months. A short step-by-step guide on how to install the certificate can be found here.

URLRewrite : HTTP to HTTPS Rule

A quick rule to use with IIS UrlRewrite to redirect all HTTP requests to their HTTPS equivalent.

1
2
3
4
5
6
7
8
<rule name="HTTP to HTTPS" stopProcessing="true">
  <match url="(.*)" ignoreCase="false" />
  <conditions>
    <add input="{HTTPS}" pattern="off" />
    <condition scope="serverVariable" index="SERVER_NAME" test="matchRegex" value="localhost|127\.0\.0\.1|::1" negate="true" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Temporary" />
</rule>

This rule only does a straight redirect i.e. http://mydomain.com to https://mydomain.com

Update 28 Nov 2017
Rule updated to fix some occasional issues experienced with live sites. The revised rule has been used successfully with a number of sites for a couple of weeks now.

Uploading files in WordPress on IIS – WTF moment.

There are whole slew of blog posts and technical articles on configuring IIS and windows permissions to enable file uploads in WordPress sites. I’ve read them before and had cause to re-visit them over the last couple of days as I struggled to get uploads working on this site. Whenever I attempt to upload a file, the site would just site their until an HTTP timeout message appeared. No HTTP 500, just a PHP timeout error.

My IIS and folder permissions were correct as were all the paths in php.ini. As I was testing tweaks or configuration changes, I could see the temporary files being written in the PHP temp folder. In other words, the actual PHP upload was working. Something was blocking the copying of these files to the WordPress site. Was it WordPress itself or a Windows permission?

To compound my confusion, WordPress’ own update functionality was working without a hitch, so this meant the site had the correct write permissions at least on the wp-content folder.

After several hours of fustration I found the problem and it wasn’t with IIS, PHP or Windows. It was with a WordPress setting. I eventually wandered over to WordPress’ Settings > Media and the uploads folder path contained a reference to a W drive. I have absolutely no idea where this has come from. This site has never been on a server with a W drive. However, once set back to the default of wp-content/uploads, file uploads worked again.