#YOLO Programming

With Free TLS Certificates And Fantastic Tooling, There Are No Longer Any Excuses Not To Use HTTPS

Now that I've got your attention, the astute reader may have noticed that (at the time of writing), this blog is not using TLS.  That's because we currently sit on a shared hosting plan on Azure which does not support certificates for custom domains.  So there, that's one excuse (which we will be rectifying shortly).  But other than that, after reading this post you won't have any excuses.

Update

Thanks to Justin's comment below, even our one excuse was not a good enough reason to not have TLS.  You guys really are the best.

Recently I moved an old website that I run in my basement to a new install Windows VM (cheap plug alert; get free e-books at bookgoldmine.com) and thought it would be a good idea to get a tls certificate, particularly on Windows Server 2016.

Why use HTTPS on a website that has no sensitive information?

Bookgoldmine.com, like most other websites, has no sensitive information on it.  No logins or anything of the sort.  So why bother with a secure connection?  Lots of reasons:

The two major roadblocks to TLS, like most things in life, have traditionally been time and money.  Obtaining a certificate takes time and requires some skill.  Though the price of certificates has been coming down, requiring someone to take out their wallet is a roadblock, particularly for owners of smaller websites.

Let's Encrypt

Let's Encrypt is an open certificate authority (CA) that seeks to rectify both of those problems.  It's free and automatic.  You can't ask for much more than that.  Ok, well I can, because for as wonderful of a service they provide, their certbot does not run on Windows.  Luckily, there's a handful of 3rd party implementations that do

letsencrypt-win-simple

https://github.com/Lone-Coder/letsencrypt-win-simple is a .net client built around ACMESharp, which is a library that implements the ACME (Automated Certificate Management Environment) protocol, which is what makes all of this so easy to use.  We really are standing on the shoulders of giants, and I thank all of the people that have built up this fantastic stack.

This tool is so simple to use, I almost feel silly writing the following how-to guide.  But I have a quota to fill, so I will.  Note that there are plenty of ways to use the tool, but I will be covering the easiest.

  1. Download the executable to your server.  Or build it yourself, you rebel.
  2. In a command prompt, go to the the letsencrypt path you chose in the previous step, and type letsencrypt.exe
  3. Either select the host you're interested in, or type A for all hosts
  4. The tool creates a scheduled task to renew your certificates, which have a rather short shelf life (3 months).  You'll be asked if you want to change the user it runs as.  I selected "No"
  5. In Windows Task Scheduler, notice the new task "letsencrypt-win-simple httpsacme-v01.api.letsencrypt.org."  Out of the box this task will only run if the user is logged in.  I'm never on my server, so this won't work for me; so either select a system user like SYSTEM, or select "Run whether user is logged in or not" and type your password in.  If your password changes regularly the latter option is not a good one.

Yay! We have https!  But users have been going to my little website for 10 years now, so no one will actually go to the https version.  We'll want to redirect them.  Using the power of grayskull webconfig, 

we can do this easily.  In the <system.webServer> section, copy and paste the following:

<rewrite>
    <rules>
        <rule name="Redirect HTTP to HTTPS" stopProcessing="true">
            <match url="(.*)"/>
            <conditions>
                <add input="{HTTPS}" pattern="^OFF$"/>
            </conditions>
            <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
        </rule>
    </rules>
</rewrite>

Update

As Seferan pointed out below in the comments, for the above to work you need to have installed the rewrite module.  As always I appreciate the feedback!

And that's all there is to it.  So what are you waiting for, secure that website!

Comments (9) -

  • Seferan

    12/30/2016 4:03:00 AM | Reply

    Your webconfig configuration will require URL Rewrite (www.iis.net/downloads/microsoft/url-rewrite) to be installed on the web server.   In my opinion, companies should be installing URL Rewrite as part of their standard IIS install, unless they have extreme high optimized web servers, so this shouldn't be a big deal.

    • Gio

      12/30/2016 4:08:42 AM | Reply

      Excellent point, and I will make a note of that in the article.  Thank you for the response!

  • Justin

    12/30/2016 7:19:40 AM | Reply

    FYI Azure shared doesn't have to be a reason not to setup https: www.troyhunt.com/.../

    • Gio

      12/30/2016 10:58:47 AM | Reply

      Thank you, I will look into this later today!

    • Gio

      12/30/2016 8:02:22 PM | Reply

      OK, we followed the steps and it's working!  Thanks Justin!

  • Dan Atkinson

    12/31/2016 12:32:47 AM | Reply

    Those are some interesting SANs lumped in with your SSL!

    • Gio

      12/31/2016 5:17:44 PM | Reply

      We followed the steps outlined by Seferan above to get SSL on our "shared plan" Azure (aka the cheapest plan) account, which basically means putting the website on CloudFlare, and I guess this approach to dishing out free SSL was the most effective for them.

      I 100% knew some of our readers would checking our cert though.. I love that!

  • Pino

    1/1/2017 8:48:03 PM | Reply

    For public sites whose users all have high-speed Internet access, this is fine. But HTTPS breaks for private sites or users in an Internet desert.

    1. Browser publishers require CAs to issue only certificates that identify a fully qualified domain name (FQDN). A server on a private home network intended for use by BYOD clients is unlikely to have a FQDN, instead being named by its private IP address or by a hostname under a made-up top-level domain such as ".local".

    2. It loses a heuristic for which requests a client in an Internet desert will try to send through a caching proxy near the client. It used to be common that public sites would use cleartext HTTP, which can go through a caching proxy, and private sites would use HTTPS, which goes through either a direct connection to the Internet or through a tunnel. This made the best use of, say, a 128 kbps uplink for a whole village. But now that everything uses HTTPS, there's no automatic way to send requests to public sites, such as news or encyclopedia, through the caching proxy, but divert requests that the user would reasonably want to hide from the proxy operator, such as banking information, through a channel that the proxy can't snoop.

    • Gio

      1/3/2017 5:47:06 PM | Reply

      You make excellent points, particularly your point about caching.  At the end of the day though, we can't have our cake and eat it too.  Even Wikipedia, the go-to encyclopedia for pretty much anyone, switched to "https everywhere" in 2015, despite the performance concerns you mentioned, because they felt the stakes were too high.

      Though, to your point, I do wonder how strongly I'd feel about TLS on a site like Wikipedia if I had to struggle with low bandwidth, assuming I were in a country with reasonable  privacy laws (if such a place even exists anymore).





Add comment

Loading

Monthly Archive

The file '/Custom/Widgets/ScriptInjection/widget.cshtml' does not exist. The file '/Custom/Widgets/ScriptInjection/widget.cshtml' does not exist.