Let’s Encrypt Extension for Azure App Services

Let’s Encrypt Extension for Azure App Services

Thanks to Simon J.K. Pedersen (https://github.com/sjkp) there is now a reasonably easy way to get auto-updating “Let’s Encrypt” SSL certificates in you Azure App Services using the “Azure Let’s Encrypt” Extension (https://github.com/sjkp/letsencrypt-siteextension).

There are some very comprehensive install and setup steps here https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install

I found that I needed to ensure that all the App Settings were correct to get things going as the automatic install didn’t quite do it and threw a couple of exceptions. Although I think an update may have fixed this now.

These are the App Settings I have and all is working well.

The issues I encountered:

Error: “No route registered for ‘/letsencrypt/’” when you first try to go to the extension config page

Resolution: Just restart the app service and all should be OK

Error: “‘authority’ Uri should have at least one segment in the path…” when clicking next on the first page of the automatic installer.

Resolution: Manually populate any missing App Settings as shown above.

Error: “Access to the path ‘.well-known\acme-challenge’ is denied.” when attempting to request a certificate.

Resolution: Enter the default path into the ‘letsencrypt:WebRootPath’ regardless of whether the site is in the default location or not.



3 thoughts on “Let’s Encrypt Extension for Azure App Services

  1. Do you know why this doesn’t work behind azure traffic manager? Their github repo says
    “No support for multi-region web apps, so if you use traffic mananger or some other load balancer to route traffic between web apps in different regions please dont use this extension.”

    Just curious as to why.

    1. I suspect it has something to do with making multiple certificate applications to LetsEncrypt for the same FQDN from different servers. I think only one server can make a certificate request for a given domain. It essentially becomes the CA. A second request from another server for the same FQDN will either be rejected or the previously requested certificates revoked.
      However, in theory, there is no reason why you shouldn’t be able to use the same certificate across all your regional instances so long as they have the same FQDN(s). As a strategy, it may be best to have one app service (primary) responsible for the certificate requests and renewal. Then a scheduled PowerShell task to copy and import the certificates from the primary to the other regional App Services. Do let me know if you find a solution.

    2. Hi Wes,

      The certificates works fine for azure traffic manager, it is the renewal process that I can’t automate. (Or well, it can be done it is just complicated).

      The problem with the renewal process is that the challenge file needs to be on all web front ends, but the way the extension works is that it writes it to the file system on the server where the extension is installed. So if you e.g. have a region based setup with web apps in multiple regions the challenge file will not be on every web front end. When the Lets Encrypt servers tries to validate the ownership by browsing the challenge file they risk accessing a web front end without the challenge file and get a 404 which will result in no certificate being issued for you.

      In the latest version of the extension however 0.8.5 you can use a DNS challenge and if you choice to go that route (requires you to use Azure DNS) then you can request a certificate just fine, as the challenge file is not part of the process any more.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.