Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

Moving to Lets Encrypt SSL Certificates


:P
On this page:

This week marked the expiration of the last paid for SSL certificate that I still had running, and moving off all of my sites to LetsEncrypt. I've talked a bit about LetsEncrypt in a few posts recently and as you can probably tell I'm fairly enthused by the fact that I can now use free SSL certificates on all of my sites, including those that previously I would have not considered SSL certs for in the first place. With SSL being free and easy to administer, it's become much easier to say "all my sites are SSL" from now on.

In this post I'll describe how I'm using LetsEncrypt with Windows and using a pre-release version of the Certify GUI Client to manage my Lets Encrypt certificates.

Moving off of paid SSL in Stages

I run 16 sites on my server 5 of which were originally using SSL. With the advent of Lets Encrypt and free certificates I moved all but three of the sites over to SSL. SSL is becoming more important as search engines are starting to rank sites using SSL higher.

But also as a general purpose security feature, SSL protects content from prying eyes, man in the middle attacks and password and cookie snooping. SSL has always been important for sensitive sites that publish data that can't be exposed, but it's becoming important even for non-sensitive sites just to protect cookie and password high jacking. SSL is really starting to become a requirement rather than an option if you capture any data at all from users.

In my case the unsecured sites were mainly hobby or internal use sites that were only used by me and few associates, so nothing really public facing. But even these sites are a potential security risk for things like logins if not properly secured. SSL is a good thing, but in the past, even spending $15 a year for a low impact site - plus the hassle of renewing with a vendor and then the certificate installation was enough to not do it in many cases.

When Lets Encrypt rolled around all that changed though. I started with a few of those previously open hobby sites and tried out Lets Encrypt. I run on a Windows Server so initially the tools available was pretty sparse since the official tooling from the Lets Encrypt Organization only supports Linux (a official Windows client is still in development), but things have improved and there are a number of third party libraries and tools available that make it possible to work with Lets Encrypt on Windows. I wrote about those Windows tools for IIS a few months ago.

Moving things over

After playing around with the various solutions with my trial sites, I ended up settling on using Certify. Certify is a Windows GUI utility, which means the process is not 100% automated, but I prefer to have an easy visual way to verify my certificates and interactively renew them which takes but a few minutes for all the sites once every few months.

For testing I ran for two months with the new certificates on my trial sites and went through the process of renewing them to see the whole workflow and notification process in action. It's important you find the right way to do this because Lets Encrypt certificates have a maximum expiration of 3 months which means you have to renew every three months at least. Whether you automate this process using the ACME libraries or LetsEncryptWin or whether you use a GUI utility like Certify, just make sure you use the approach that works for you.

After the initial trial period and finding the workflow that worked for me, I moved all of my existing sites to LetsEncrypt as well.

Wild Card Domains

As I mentioned I just moved my final sites over to Lets Encrypt. The last domain that just expired was my *.west-wind.com wildcard domain certificate. Wildcard domains are nice because it makes it very easy to assign sub-domains for all sorts of things. I run about 15 sub-domains like this blog (weblog.west-wind.com), my support site (support.west-wind.com) and various product sites (markdownmonster.west-wind.com, websurge.west-wind.com etc.) as well as some internal test and dev sites under the west-wind.com domain.

Let's Encrypt doesn't support wild card domains, but given how you administer Let's Encrypt certificates that's not really a problem as you can easily generate certificates for all your sub-domains with Lets Encrypt, and then assign them. Using the workflow provided by any of the Lets Encrypt tools it's actually easier to do this than to manage a wildcard certificate in IIS, because the tooling combines the process of creating the certificate and installing it into IIS in one step. In a way, Certify and Lets Encrypt become my IIS certificate manager.

Certify

After playing with the various solutions I ended up settling on Certify for now. Certify is a GUI Windows client that lets very quickly and easily set up, and later renew certificates. The tool handles both creating the certificates and binding them to IIS Web sites. Under the covers this tool uses the main .NET based Windows ACME library to provide its functionality. Several other tools also use this same library.

To be clear Certify is still pretty rough and is an alpha product, but besides some of the quirks and lack of high level features (like an easy way to renew all certs), it's still very easy to use and very functional.

Walk through Certify

Certify, like all Lets Encrypt based clients, should be run on the server that you plan to install the certificate on and where the base domain you are trying to create exists. A site has to exist on the root domain. So if you want to register any subdomain for yourdomain.com make sure that yourdomain.com is up and running. Also make sure the domain does not auto-redirect to another domain including to a SSL domain (that bit me on one of my sites).

Let's Encrypt certificates are only validated by their hostname and DNS mappings which is why the above works as it does.

Windows Server 2012 required

Note that Lets Encrypt creates hostname bound SSL certificates which means that the certificates that are mapped to the IP Address, port and hostname. On IIS this means you need to use SNI (Server Name Identification) which is supported only on Server 2012 and later. Client versions of Windows 8.0 and later also support it. However Lets Encrypt will not work on Server 2008 or older!

Creating a new Contact

To start you need to create a contact which is the admin contact that will eventually receive renewal emails for the certificates.

All certificates that you create from here on out are then bound to this or any other contacts that you configure in the above dialog.

Create New Certificate

Next you'll create a new certificate. Here you basically pick an IIS Web site that you want to create certificate for:

Notice that I selected the port 80 site. If you don't have an SSL binding to port 443 for the site yet, Certify will create the new binding and add it to IIS. If you already have a 443 binding you can also select that and Certify will figure that out as well.

If all goes well, after a few seconds you'll have a new certificate:

If you now go into IIS you'll find a new binding for port 443:

And you're done!

Multiple IP Address Bindings

If you have multiple IP Addresses on your server I recommend that you explicitly assign the certificate in IIS to an IP Address. Certify applies the certificates to All Unassigned which can cause problems if you have multiple IP Addresses. I've seen certificates randomly switching to the wrong IP address and then no longer validating properly. So, I recommend to always explicitly set the IP Address. It'd be nice if Certify/ACME would automatically pick up the explicit IP Address from the base domain.

If all of that worked you should now be able to access your site via SSL:

SSL Secured Web site

Yay!

Consider how easy and quick this process is. You can literally have a new certificate bound to a site in less than 5 minutes even if you're running this tooling for the very first time which is freaking awesome compared to the process I had to go through even just with dealing with an SSL vendor.

Renewing Certificates

When a certificate is set to expire, LetsEncrypt sends out notification emails which remind your to renew your certificate.

Using Certify, renewing is as easy as pulling up the site from the list and selecting Renew from the shortcut menu:

Renewals tend to take a little longer so they don't immediately refresh the UI - you have to reload the vault to see the update in the UI. But again it only takes a few seconds.

Gotchas

There are a few gotchas to watch out for with lets encrypt that bit me while updating.

SNI

Lets Encrypt requires SNI (Server Name Identification) when using IIS so that you can bind multiple SSL certificates to a single IP address. Prior to SNI (which was introduced in Windows Server 2012 and Windows 8.0 (IIS 8)) SSL required a dedicated IP address for each SSL certificate which was a major stumbling block for SSL usage (and another reason why I didn't use it as I was running on Server 2008 up until late last year).

On IIS it's very important that you make sure that every SSL binding tied to a particular IP address (or the 'unassigned' site) is marked as SNI:

if there's just one site that's not tied to SNI for a particular IP Address, you'll end up getting SSL errors for all but one site.

This is a major fail in the IIS Admin UI - it shouldn't allow for this to happen, but as it is it's an easy mistake to make, and a difficult one to track down. You can use:

netsh http show sslcert

to show all http.sys port 443 bindings which also shows whether SNI is enabled, but if you have a few certs installed it's difficult to see the state easily there as well. It's best to be very careful when you create your certificate for the first time and ensure that SNI gets and IP port binding gets set correctly.

Renewals automatically use the existing mapping, so this tends to be a one time check you should make when you first install a new certificate.

IP Addresses

If you have more than one IP Address on your server make sure to bind every site to an IP Address rather than using All Unassigned. I've had various problems with IP Addresses jumping on domains and as a result SSL certificates randomly not working.

When that happens you'll see the red Https warning box in the address bar. The same rules as with the SNI note above applies - after initial creation of the new binding from Let's Encrypt make sure you double check the binding and ensure SNI is enabled and you are bound to a specific IP.

What about Wildcard Certs

As I mentioned when I replaced all of my certs I also replaced my wild card certificate. But Lets Encrypt doesn't support wild card certs. So what did I do? It simply doesn't matter. Although wild card certs aren't supported, I can now create individual certs and assign them to my sites instead. Because I've simplified my IIS configuration process through Certify's interface, I'm removing the IIS mapping step that I can now do in Certify. Either way I needed to configure the certificate and the steps to do it with an explicit cert is no more involved than assigning a cert inside of IIS's manager. IOW, the process is different, but it's no more complex with individual certificates now.

No Extended Validation Certificates

Lets Encrypt is limited to basic SSL certificates, which means it only provides for the lowest level of SSL validation which validates that you own the domain that you are certifying. This works fine if all you need to do is secure you're content, but you don't need to more vigorous validation that provides extended company identification.

You won't get an Extended Validation (EV) certificate that gives you the full company green bar. If you need this level of SSL certificate you still need to buy a certificate from a commercial certificate authority.

Making life Easier

For me moving all my certificates to Lets Encrypt and using Certify has made my life much easier even though I've actually added a number of new certificates. The reason for this is that now I have a central place where I can manage all my certificates and administer their assignment into IIS. It's one place were I can go and check on status and if necessary renew the certificates. It's also saving me $200 a year that I used to spend on certificates.

The benefits of this approach are:

  • Free SSL Certificates
  • Central Storage of Certificates
  • Easy to unify dates for all certificates
    (so you can update all at once)
  • Easy assignment to IIS Sites
  • Save some money

Once certificates have been set up I can check in once every three months (when the Lets Encrypt renewal notices pop up) and spend 5 minutes to update all the certificates and I'm done for another 3 months. If I run into a problem with cert or the keys get compromised I can easily renew any of the certs or all of them at any time.

Since I have a dozen domains here this takes a few minutes at best which is fast enough.

Compare that to upgrading paid certificates with renewal process, waiting for approval, unpacking the certificate and installing it into IIS this is a fraction of the time it used to take me.

So, if you haven't played with Lets Encrypt and automated certificates and you use certificates I recommend you take a look and check it out. I think you'll find that this process greatly simplifies certificate management and reduces costs as well. It'll be interesting to see what this ends up doing to paid providers (which like Commodo who are actively trying to disrupt and discredit LetsEncrypt), or if it will drive down prices and more importantly make it easier to deal with certificates. These new tools are showing that the process of certificate management doesn't have to be the special kind of hell we've been put through for all these years.

Related Posts

Posted in Security  LetsEncrypt  

The Voices of Reason


 

Gfw
July 15, 2016

# re: Moving to Lets Encrypt SSL Certificates

Question...

What made you choose Certify over Win-Simple? I had issues with Certify when I initially started so I went with Win-Simple on about 8 websites. The automatic renewal feature works great.

BTW... great articles on LetsEncrypt, it was your first article that got me started.

Rick Strahl
July 16, 2016

# re: Moving to Lets Encrypt SSL Certificates

@GFW - I ended up with Certify because there's nothing to set up or configure and to be honest I like to run a GUI where I can easily see what's set up. However, Win-Simple works just fine as well, and is also very easy to start with, but it's not quite as easy to see what's set up and configured. Last I looked too it wasn't very clear how to remove sites or force an immediate renew. That may have changed by now though.

Basically it comes down what you prefer: Command line tooling or something a little more visual that you can use interactively.

Mike
August 10, 2016

# re: Moving to Lets Encrypt SSL Certificates

Rick,

Currently for security reasons I really only want port 443 open for my website. So every time I want to renew this cert I guess I would need to open port 80 temporarily so the challenge path/file could be found?

If I did leave port 80 open so that I could script some type of renewal process how would that even be secure then? I wouldn't want users trying to login on the http part of the site.

Thanks,

Mike

Mike
August 10, 2016

# re: Moving to Lets Encrypt SSL Certificates

Maybe just block all ip addresses on port 80 except for Lets Encrypt (if they have a static ip address)

Rick Strahl
August 11, 2016

# re: Moving to Lets Encrypt SSL Certificates

Once port 443 has a cert on it I think you can specify an https url. But you have to effectively re-register the site to make that work. I haven't tried that but that should also work.

Jon Hanna
November 07, 2016

# re: Moving to Lets Encrypt SSL Certificates

"On IIS this means you need to use SNI (Server Name Identification) which is supported only on Server 2012 and later. Client versions of Windows 8.0 and later also support it. However Lets Encrypt will not work on Server 2008 or older!"

This isn't true, though it may be for the Certify GUI (I haven't tried that). If you have an IIS 7 site on Server 2008 that has the host(s) concerned bound on port 80 (this may be in addition to an IP any-host binding if you want, so the host binding could be a redundant binding serving to label the site for this purpose) then using letsencrypt-win-simple you can get a certificate for the site that will then be given HTTPS bindings for both the specified hosts and also the appropriate emtpy-host IP binding. This includes working fine with multiple different sites set up that way on the same server. It also allows for automatic renewals.

Again, I don't know if that would also work with the Certify GUI as I've never played with that, but if it doesn't then that restriction is with the GUI not with Let's Encrypt.

Timothy
July 28, 2017

# re: Moving to Lets Encrypt SSL Certificates

I installed Lets encrypt on my website with an ip, but later my host changed my ip (nameserver). After the change of the ip, the ssl certificate got expired and since then https problem has become uncoming on my computer system. Please assist with ways to resolve for ip from an apache server. Thanks


Rick Strahl
August 02, 2017

# re: Moving to Lets Encrypt SSL Certificates

@Timothy - not sure what you mean. AFAIK, LetsEncrypt can only create certificates for domain names, so if the IP address changes that should have no effect on the certificate. Make sure that the domain name you are using always stays exactly the same (ie. www. prefix, no prefix etc. all have to be separate registrations).


Jeff Franczak
December 02, 2017

# re: Moving to Lets Encrypt SSL Certificates

Thanks Rick for taking the time to share your experience with the community. After reading this post and your other on Windows tools for Let's Encrypt, I installed Certify 2.1.27 on my AWS EC2 Server 2012 R2 instance and had an Let's Encrypt SSL certificate installed and tested in less than 15 minutes.

  • Jeff

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024