HTTPS or HTTP over TLS (formerly SSL) is no longer an optional component when you build a Web site today: It’s a requirement. Encrypted connections hide traffic on the wire and make it much more difficult to hijack HTTP connections or steal valuable cookie information to reuse in playback attacks. TLS can also prevent a host of drive-by and man-in-the-middle attacks that are all too easy to instigate over non-secure connections in any public space. TLS keeps data secure while users are sending and receiving data, making it much harder to "listen in" on a connection on the Web. It’s not a panacea for all security issues, but it’s big fat low-hanging fruit to start with, and your site should proactively encourage this secure-by-default behavior.

As a response to the security concerns, we’re now seeing many new Web features that require secure connections. The Geolocation APIs in Chrome now only work over secure connections. Most Google APIs that you can integrate with on your website today like maps, geolocation, translate, graphs and so on, all must originate from secure endpoints of your source site in order to work. Another important milestone is the newish high performance HTTP2 protocol that only works over secure connections. Other new Web network protocols are following suit. The day is fast approaching when unsecure connections will be relegated to a shunned digital backwater.

The day is fast approaching when unsecure connections will be relegated to a shunned digital backwater.

Google seems to be leading the charge, as they were the first to force some of their APIs, like Geolocation, to work only over TLS. Chrome now also flags websites that don’t run HTTPS with a warning icon, as shown in Figure 1. Figure 2 shows a site that has a secure certificate installed and the message shown there is much more confidence-inspiring.

Figure 1 : Non-HTTPS websites are flagged with a warning in the address bar.
Figure 2: Sites with an HTTPS Certificate and secure content show a reassuring secure icon and message.

But even more to the point for the Web at large, back in late 2014, Google’s search engine algorithm started down-ranking non-secure sites in favor of secure ones. More recently Google started showing non-secure sites with a warning icon (Figure 1). This really hits website owners where it hurts, because traffic is the currency that drives investment and profit for most websites. And it seems to be working. HTTPS adoption has been on a rapid rise over the last couple of years.

HTTPS is no longer an option; it’s now a requirement for a website.

In short, TLS is no longer an option but a necessity for any website, large and small. And now, with new tooling and free certificates available from Let’s Encrypt and a few other providers, there’s no longer any excuse to not use encrypted HTTP, even on small hobby or sample sites. Anything public should just run on HTTPS. Setting up a new certificate, even on Windows and IIS can now literally be done in a few minutes and the renewal process can be fully automated. It’s essentially fire and forget. If you haven’t secured your sites yet, this article is for you.

In this article, I show you how to set up a certificate and get it installed in IIS via some of the automated tools. There’s not much to show because it’s so easy, but my goal with this article is exactly that: Show that it’s a no brainer task and there’s no reason to put off getting your site to run under TLS.

Let’s get to it.

Free Certificates for All

A few years back, the Internet Security Research Group (ISRG), which is a consortium of sponsors that includes the Electronic Frontier Foundation, Mozilla, Cisco, Google, Facebook, and many others, started setting up a new Certificate Authority with the goal to provide free and fully automatable certificates to the public. Due to the benefits of TLS, they felt that it’s important enough to tackle this space and challenge the up-to-then entrenched providers. A host of other big network names jumped onboard to provide support and funding for this project with the goal to provide free and easy-to-manage certificates to the Web community. Certificate issuance is big business and it’s no surprise that along Let’s Encrypt’s way, there were some interesting attempts to interfere with the progress by some of the big entrenched certificate providers. In the end, Let’s Encrypt made it to production and has been a huge success in the last couple of years, since its initial release. Let’s Encrypt has been a huge driving force in the adoption of HTTPS connections. At the end of June, Let’s Encrypt had served over 100 million certificates in less than a two-year timespan.

Free is a big motivator and it’s reflected in this adoption rate. Personally, I’ve been running a number of small personal sites. Although certificate prices for non-validated certificates had been dropping significantly even in years prior to Let’s Encrypt’s emergence, even $20 for 10 sites adds up to real money. If you add in the time it took to manage the upgrade process and installation, there were resources and some significant effort involved. For personal sites, it was often a matter of writing it off as "too much effort."

But with the cost factor gone, plus next to zero administration, everything changes.

Certificate Automation

If you’ve been around doing Web development or Web administration over the years, you probably know that installation and management of certificates has been a major hassle. Between the cost of certificates, applying and renewing certificates and managing the process of generating certificate requests and then installing final certificates into servers was always a pain, especially on Windows with IIS with its broken certificate renewal system that only seemed to work with Microsoft’s own generated certificates. Updating a certificate always seemed like a dreadful task to look forward to.

Let’s Encrypt provides a completely open API to manage the certificate request and retrieval process. In combination with high-level tools that automate the API, it’s possible to compress the entire certificate generation, retrieval, and renewal process into a very short process that takes less than a minute. The client tools can then also install the generated certificate right into the Web Server, ready to serve requests immediately.

To me, this has been the biggest selling point of Let’s Encrypt, even more so than the free factor. In the past, I’ve had about 15 certificates that I had to renew over the course of the year. So, pretty much once a month I’d have to renew one certificate or another and each time it takes a little time out of my day to do so. First, I had to apply for a certificate, send in a request, then wait a few hours get the request back, build the final certificate that I could install in the certificate store and then bind it to IIS. The process isn’t hard, but it was spread out over the course of a few hours asynchronously. Rinse and repeat for a renewal 15 times a year. Blech.

Let’s Encrypt changes that entire process through its open ACME API, which automates the entire process of certificate generation. Rather than dealing with a different company each time, you use a common ACME client implementation that directly talks to the automated API to create and issue a new certificate in about 30 seconds. Likewise, the API supports updating and renewing certificates through an automation API endpoint.

Native Let’s Encrypt tooling (https://certbot.eff.org/) provided by the EFF and the Let’s Encrypt foundation is supported only on Linux and Mac, but there are several ports of the ACME client protocol including a number of .NET-based libraries that runs on Windows. One such implementation, ACMESharp (https://github.com/ebekker/ACMESharp), has become the basis for most of the high-level tools that sit on top of it and provide an easy interface to managing certificates.

Limitations

Okay, Let’s Encrypt sounds awesome, but it’s not all rainbows and unicorns. Before I take a look at how to create a new certificate and install it in IIS, there are a few things you should understand about some limitations of Let’s Encrypt Certificates:

Certificates are domain validated. Because Let’s Encrypt uses an automated process, there’s no background check or other validation beyond a DNS domain validation. Basically, you run the certificate request from the domain that’s to host the certificate, which validates that you control the domain you’re generating the certificate from. Beyond that, there’s no additional validation. If you need Organization Validated or Extended Validation certificates (the green label certs that show a company name), you still need to use a commercial provider and pay the big bucks. These certificates not only aren’t free, but they’re very expensive. These certificates aren’t any more secure, but they’re backed by background checks for the companies that use them, which provides an extra level of confidence for users of a mainstream site. The green bar isn’t about security; it’s mainly about trust and optics in the browser bar.

No wildcard certificates Currently, there’s no support for wild card domain certificates available from Let’s Encrypt. For small sites that have one or even a few websites on a single domain, this isn’t much of a problem. But if you’re building multi-tenant applications that might have many sites on various sub-domains, this can become a problem. Although you can easily create certificates on subdomains using automation, there are some limits in how many you can create quickly without hitting Let’s Encrypt rate limits. Let’s Encrypt promises wild card certificates in 2018, but we’ll have to wait and see how that implementation work for validation.

Rate limits. Let’s Encrypt has rate limits regarding how many new certificate requests you can make for a given domain within the course of a week. LE recently upped the rate from five to 20 requests a week. I frequently ran into the rate limits with five requests, especially when first experimenting with Let’s Encrypt, which can be frustrating because you’re effectively locked out for seven days once you hit the limit. You can check the rate limits here: https://letsencrypt.org/docs/rate-limits/.

Certificates expire after a maximum of 90 days. Let’s Encrypt certificates have to be renewed more frequently than traditional certificates, which are typically valid for a year. More frequent renewals ensure that if there ever is a breach (not that there has been one), it doesn’t get exploited for long. On the other hand, if you’re using Let’s Encrypt with auto-renewals, it doesn’t really impact you much because the renewals are fully automated, so this isn’t as big an issue as you might think.

Let’s Encrypt currently has no support for wildcard domains which means that each and every domain has to have its own certificate.

Creating a Certificate on Windows

There‘s no official Let’s Encrypt client for Windows provided by Let’s Encrypt, but there are a number of third-party providers. I’m going to look at two different tools here that address two slightly different use cases:

LetsEncrypt-Win-Simple (https://github.com/Lone-Coder/letsencrypt-win-simple)

Certify the Web (https://certify.webprofusion.com)

The first is a very easy-to-use command-line tool that you essentially run once to configure an individual website. The second is an easy-to-use GUI tool that provides a lot of additional functionality in customizing and managing certificate requests along with a nice visual way to see certificates and their status. Both tools can have you up and running in minutes.

LetsEncrypt-Win-Simple is a very simple command-line utility that can get your certificates created and installed in couple of minutes.

LetsEncrypt-Win-Simple

Lets-Encrypt-Win-Simple is a very easy to use command-line utility that lets you get Let’s Encrypt going on an IIS-based Web Server in a couple of minutes. Literally. To get the utility, go to the Let’s Encrypt-Win-Simple GitHub repository and the Releases page here: https://github.com/Lone-Coder/letsencrypt-win-simple/releases.

To get going, use these steps:

  1. Download the latest non-beta zip file to your Web Server.
  2. Unpack the resulting files into a folder of your choice.
  3. Open an admin command prompt.
  4. Type Let’s Encrypt. First time execution asks you for a contact email for notifications/renewals. This brings up a list of IIS Web Sites of the server.
  5. Pick a site with the number from the left. Press Enter.
  6. Watch it go…The process should only take about 15 seconds.
  7. You’ll be prompted to add a scheduled task for renewals.
  8. Put in account info for the account to run the scheduled task under.

Done!

Figure 3 shows what this process looks like from the command line.

Figure 3 : LetsEncrypt-Win-Simple creates a new TLS certificate in less than a minute.

If you think this is just too easy, you’re not alone. When I first ran LetsEncrypt-Win-Simple and had it work effortlessly in one minute, I was blown away. Compared to my old manual process using Let’s Encrypt’s automated process, it’s ridiculously simple.

And that’s really the main point of Let’s Encrypt: The automated process, even more so than the free pricing, makes Let’s Encrypt a no-brainer for adding HTTP encryption to your site.

Figure 4 shows a happy HTTPS enabled site and certificate.

Figure 4 : When it’s all done, I have a valid LetsEncrypt Certificate and a green browser bar.

Certify the Web: A Richer GUI Client

It’s hard to beat the simplicity of Let’s Encrypt-Win-Simple, but if you want a little more control over the certificate management process, how certificates are created, trigger actions on creation, renewals and failures, or simply to get more useful error information if something goes wrong, take a look at Webprofusion’s Certify the Web (https://certifytheweb.com), also known as Certify for short. Usually, you think of a GUI application as a dumbed-down version of a command line API, but here, the opposite is the case: The app piles on a bunch of useful features to customize the certificate generation and management process.

Figure 5 shows Certify the Web’s advanced certificate configuration page and you can see that there are a host of options available. The options are just that, too: optional. If you’re the "just get it done" type, the defaults get you a certificate in a few seconds. At its simplest, you just choose New Certificate, select your IIS site from the drop-down list, and hit Request Certificate. First-time users should also use the Configure Auto Renew option to set the credentials for the scheduled maintenance task.

Certify the Web provides a nice GUI for managing certificates along with some advanced options and support features..

Figure 5 : Certify the Web provides a rich GUI client to Let’s Encrypt with many advanced admin features.

Behind the scenes, Certify uses the same ACME .NET APIs that Let’s Encrypt-Win-Simple uses, but Certify makes the process more interactive so you get to see what happens in more detail. Certify also can sense a number of configuration issues (e.g., IIS configuration and DNS settings such as CAA and DNSSEC) before making certificate requests, which helps to avoid API rate-limiting problems and takes the guess work out of troubleshooting.

Advanced users can choose to individually configure each certificate and have the option to specify validation protocols (such as validating a site via HTTP or TLS for certificate requests selectively). You can also group together several subdomains into a single group (or list of Subject Alternative Names, or SANs) that are submitted as a single certificate request to Let’s Encrypt, which makes it easier to manage many subdomains of the same site. This is especially useful for multi-tenant applications and gets around the domain overload that can occur if you’re running a lot of subdomains on a single IIS box.

Certify the Web also supports executing scripts for pre- and post-processing with PowerShell scripts or Web Hooks that allow a backend application to monitor renewals and domain registrations for each site. The PowerShell options are especially useful if you need to manipulate, export or otherwise re-use the renewed certificate for services such as Remote Desktop or Exchange). You can even choose to revoke your certificates as an added level of security.

Please note that Certify is not a free tool. You can manage up to five sites/certificates for free, but any additional sites require a paid license at a reasonable cost (https://certify.webprofusion.com/register). A professional license is available for unlimited certificates on up to three servers and there’s an enterprise version that supports unlimited certificates for up to 100 servers. Free licenses are available for organizations who contribute code to the open source project (https://github.com/webprofusion/certify). It’s worth bearing in mind that if you have many sites, you can mix and match completely free options like LetsEncrypt-Win-Simple and still use Certify for other sites on the same server, depending on your requirements. It’s worth trying out all the available tools to see which works best for you.

For administrative installations, Certify is an excellent choice for managing a lot of related certificates easily. The notification hooks are an especially nice touch that allows administrators to get properly notified if something goes wrong in the registration or renewal process, which is a major issue if you’re dealing with hundreds of certificates on a server.

Certificate Creation Troubleshooting

Here are a couple of things you need to be aware of when creating certificates on your IIS Web Server. Although the process of creating certificates is fully automated for any of the tools you’re likely to use, there are a few things that can throw things off if your website does some custom routing or URL Rewriting. Here are a few things that have tripped me up before.

The .well-known Virtual Folder Structure

Let’s Encrypt uses a specific domain validation process (called an http-01 challenge) that involves creating and then accessing a temporary .well-known virtual directory underneath the website you are creating the certificate for. The Let’s Encrypt clients create the folder and then place several validation files there that the Let’s Encrypt authority picks up for verification. The files are extension-less JSON files that are enabled by clearing out all IIS handler extensions for that folder and mapping all files to the StaticFileModule in a custom web.configfile that’s placed in the target folder.

It’s important that this process can work, so if you’re using IIS Rewrite rules that re-route every request, you may have to turn those off temporarily to get the initial certificate installed. If you’re already using a certificate, it’s also a good idea to allow Let’s Encrypt to hit the site with a non-HTTPS request.

Note that if you’re using an older version of Let’s Encrypt-Win-Simple, the provided web.config didn’t automatically handle the static file mapping, which caused a lot of problems for ASP.NET MVC sites that took over URL routing for extension-less URLs. This was addressed in 1.94 and later: If you use an older version, I recommend that you upgrade. You can read more about this issue and a few workarounds for scenarios where the custom web.config file isn’t enough in a blog post of mine (https://weblog.west-wind.com/posts/2017/Sep/09/Configuring-LetsEncrypt-for-ASPNET-Core-and-IIS).

WWW and Root Domains

Let’s Encrypt validates specific domains, which means that each and every DNS name you want encrypted HTTPS for needs to have a certificate. This means that if you have a root site (myDomain.com) and a www domain (www.myDomain.com) both of them have to get separate certificates. Each and every domain and subdomain requires a certificate.

According to the Let’s Encrypt website, starting in early 2018, Let’s Encrypt will offer wildcard certificates that can cover all domains under a given root domain, which will be a welcome addition. On my site, I run 15 separate subdomains for west-wind.com and having a single wildcard certificate for all subdomains would certainly reduce the clutter. As easy as Let’s Encrypt makes the process of creating a new certificate and renewing it, it’s even easier to not have to create one at all in the first place.

Other Platforms

As mentioned in the beginning, Windows is a special case for Let’s Encrypt in that there’s no official Let’s Encrypt client. The two clients mentioned in this article are the most popular ones and they are certainly up to the task on Windows. On Mac or Linux, you can use the official Let’s Encrypt clients that provide raw certificate creation services. These tools are generally low-level and don’t explicitly handle tasks like installing into a specific Web server because on non-Windows platforms there tend to be a lot more Web Server choices available. However, there are also many utilities available that specifically layer on top of the base tooling and work with specific Web servers.

You might also wonder about using Let’s Encrypt with Azure. Unfortunately, there’s no direct support for Let’s Encrypt on Azure, and running a Let’s Encrypt client on Azure for anything but Virtual Machines is quite complicated. Although there are some third party add-ins available, even with those, the process is still quite involved.

Lock It Up!

If you’re still running unsecured, non-HTTP websites today, you really don’t have any excuse any longer. With Let’s Encrypt, the process to create a new TLS certificate has become so easy that there is no reason not be using HTTPS anymore. With readily available tools even on Windows, the process of creating certificates takes only a few minutes and with an auto-configured renewal process, the entire operation becomes a one-time fire-and-forget process. No more unsecured Web sites –let’s make it happen!