The blog of
Archive: May, 2016
  • Free as in ... HTTPS certificates? [Obtaining and configuring a free HTTPS certificate for an Azure Web App with a custom domain]
    Wednesday, May 18th 2016

    Providing secure access to all Internet content - not just that for banking and buying - is quickly becoming the norm. Although setting up a web site has been fairly easy for years, enabling HTTPS for that site was more challenging. The Let's Encrypt project is trying to improve things for everyone - by making certificates free and easier to use, they enable more sites to offer secure access.

    Let's Encrypt is notable for (at least) two achievements. The first is lowering the cost for anyone to obtain a certificate - you can't beat free! The second is simplifying the steps to enable HTTPS on a server. Thus far, Let's Encrypt has focused their efforts on Linux systems, so the process for Windows servers hasn't changed much. Further complicating things, many sites nowadays are hosted by services like Azure or CloudFlare, which makes validating ownership more difficult.

    As someone who is in the process of migrating content from a virtual machine with a custom domain to an Azure Web App, I've been looking for an easy way to make use of Let's Encrypt certificates. A bit of searching turned up some helpful resources:

    Nothing was exactly what I wanted, so I came up with the following approach based on tweaks to the first two articles above. The Let's Encrypt tool runs on Linux, so I use that platform exclusively. Everything can be done in a terminal window, so it's easily scripted. There is no need to open a firewall or use another machine; everything can be done in one place. And by taking advantage of the nifty ability to boot from a Live CD, the technique is easy to apply even if you don't have a Linux box handy.

    1. Boot an Ubuntu 16.04 Live CD
    2. Run "Software & Updates" and enable the "universe" repository
    3. sudo apt install letsencrypt
    4. sudo apt install git
    5. git config --global ""
    6. git config --global "User Name"
    7. git clone
      • Be sure /.well-known/acme-challenge/web.config exits and is configured to allow extension-less files:
              <mimeMap fileExtension="" mimeType="text/plain"/>
    8. sudo letsencrypt certonly --manual --domain --domain --email --agree-tos --text
      • Note: Include the --test-cert option when trying things out
    9. Repeat for each domain:
      1. nano verification-file and paste the provided content
      2. git add verification-file
      3. git commit -m "Add verification file."
      4. git push
      5. Allow Let's Encrypt to verify ownership by fetching the verification file
    10. sudo openssl pkcs12 -export -inkey /etc/letsencrypt/live/ -in /etc/letsencrypt/live/ -out fullchain.pfx -passout pass:your-password
    11. Follow the steps to Configure a custom domain name in Azure App Service using fullchain.pfx
    12. Enjoy browsing your site securely!
    Tags: Technical Web
  • Respect my securitah! [The check-pages suite now prefers HTTPS and includes a CLI]
    Wednesday, May 11th 2016

    There are many best practices to keep in mind when maintaining a web site, so it's helpful to have tools that check for common mistakes. I've previously written about two Node.js packages I created for this purpose, check-pages and grunt-check-pages, both of which can be easily integrated into an automated workflow. I updated them recently and wish to highlight two aspects.


    There's a movement underway to make the Internet safer, and one of the best ways is to use the secure HTTPS protocol when browsing the web. Not all sites support HTTPS, but many do, and it's good to link to the secure version of a page when available. The trick is knowing when that's possible - especially for links created long ago or before a site was updated to support HTTPS. That's where the new --preferSecure option comes in: it raises an error whenever a page links to potentially-secure content insecurely. Scanning a site with the --checkLinks/--preferSecure option enabled is now an easy way to identify links that could be updated to provide a safer browsing experience.

    Aside: The moarTLS Chrome extension does a similar thing in the browser; check it out!


    check-pages is easy to integrate into an automated workflow, but sometimes it's nice to run one-off tests or experiment interactively with a site's configuration. To that end, I created a simple command-line wrapper that exposes all the check-pages functionality (including --preferSecure) in a way that's easy to use on the platform/shell of your choice. Simply install it via npm, point it at the page(s) of interest, and review the list of possible issues. Here's the output of the --help command:

    Usage: check-pages <page URLs> [options]
      --checkLinks        Validates each link on a page  [boolean]
      --checkCaching      Validates Cache-Control/ETag  [boolean]
      --checkCompression  Validates Content-Encoding  [boolean]
      --checkXhtml        Validates page structure  [boolean]
    checkLinks options:
      --linksToIgnore     List of URLs to ignore  [array]
      --noEmptyFragments  Fails for empty fragments  [boolean]
      --noLocalLinks      Fails for local links  [boolean]
      --noRedirects       Fails for HTTP redirects  [boolean]
      --onlySameDomain    Ignores links to other domains  [boolean]
      --preferSecure      Verifies HTTPS when available  [boolean]
      --queryHashes       Verifies query string file hashes  [boolean]
      --summary          Summarizes issues after running  [boolean]
      --terse            Results on one line, no progress  [boolean]
      --maxResponseTime  Response timeout (milliseconds)  [number]
      --userAgent        Custom User-Agent header  [string]
      --version          Show version number  [boolean]
      --help             Show help  [boolean]
    Checks various aspects of a web page for correctness.
    Tags: Node.js Technical Web