letsencrypt-siteextension

letsencrypt-siteextension copied to clipboard

will this extension be updated to use the ACME v2 API endpoint so we can issue wildcard certificates? https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

It has been a major pain for us as Azure crawls to a halt when you have 100s of custom domains and certificates.

@modemgeek yes modem, that is my plan, unless Microsoft announces anything.

Looks like the staging environment for v2 is now available. https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605

Iis there a release date for the wildcard certificate?

February 27th according to Let's Encrypt https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html

The public version, for testing, is already available. The site https://easy.zhetao.com/ztcamen.oms?omsv=index is already using, can we add this API before the release date?

Well Im hoping that the library I'm using will be updated. If that doesnt happen, I will try to see if I can do it myself in february.

tomorrow is the release date for LE wildcard support. Has there been any success yet at supporting that with this site extension?

tomorrow is the release date for LE wildcard support.

@rastographics FYI, the release date has been delayed.

Well, the original library I used doesn't look like it is going to get updated, luckily there is a new kid on the block certes https://github.com/fszlin/certes which I will try to integrate with. However, I'm not in a rush to do so, but depending on how long they are delaying the LE release date I might be able to finish it before.

In fact the certes library should support azure as is right now. It is a commandline tool though, but I'm sure if you can't wait it is possible to find a way to automate running it.

LE released the wildcard support today. I just subscribed to this issue to see when we can add the certs to our Azure environments :)

Is there an ETA for this?

Can we help in the making of this in anyway? It's a blocker for us

Which dns provider are you planning on using @abergs

@sjkp Azure DNS, so it would be programmable.

Great, I have a PoC for that using Certes, unfortunately it generates some certificates that cannot be read by Azure Web App, I need to resolve that before I can release it.

@sjkp is the problem using subdomain wildcards in Azure? Because from what I understand the don't support sub wildcard, such as *.sub1.domain.com.

@abergs I have not tested with wildcard subdomains yet. My problem is that the certificate certes generates simply cannot be imported into azure web apps. It works on windows however, and when I export it from there it can import it into azure web apps. So I need to look into what happens with the certificate generation.

Did you solve it?

@sjkp Based on this thread/repo I created my own implementation. I can share it if you want? The implementation is however very specific, so cannot be used easily by others.

Let me know if you need some help on this. I´m trying to roll out a wildcard cert myself and got the 400 error wildcard not supported :(

@GustavoAmerico I have not had time to work on it :( Jobs that put food on the table is higher priority, and there has been a lot of those lately.

FYI: @sjkp is actively working on this (https://github.com/sjkp/letsencrypt-siteextension/commit/306a6d3864a82d3e599e75e6f2275d574f1d4113) and I just wanted to say thank you for doing it 👏

hi @sjkp thanks for great work on this feature, when we can get this feature through app service extension?

Bump. 🙂

@sjkp If there's anything we can do to help move this along, let us know.

@rbanks54 maybe you can tell me a little about your use case, because I can't really figure out how to add the functionality to the site-extension in a meaningful way.

Personally I do use Let's Encrypt for wildcard certs, but I don't use the site extension for it, as it requires DNS changes (and I feel that when you need to play with too many things outside the site, then why distribute the functionality as a site extension). That is why I build the wildcard functionality into the docker container https://hub.docker.com/r/sjkp/letsencrypt-azure, the docker container is capable of doing the same as the site-extension (request a certificate and install it to one or more azure web sites but only focuses on wildcard certs). I know I have not made any documentation about it, but there is a few features that I wanted to add before, inviting too many users onboard.

The main challenge with the docker container, is that I can't provide as easy of an installation as with the siteextension. My goal would be to have a function app that triggers a start of the docker container in Azure container instances when ever the certificate is to be renewed. But I'm afraid that the setup is going to be too cumbersome for many people, even if I do provide an ARM template. (The last I want is to release something the result in lot of support for me, that is no fun :)). You could argue that why do I need ACI and containers, I could just run everything from within the function app, and you are right in many cases that would work, but when working with DNS I have found that not all DNS servers are capable of applying the DNS changes within the 10min time window a function app can run for, which is why I opted to not build it only as a function app. The dependency on DNS also adds complexity as there are 1000s of DNS providers people use, and they all have different APIs (if any).

@sjkp can you please share some how-it-works for wildcard certs from LE? I read their forums but still can't catch idea of how many changes are required in DNS records (and deep-learning all their specs is a bit scary for me).

Is it possible to add required DNS records only once (at first cert issue) and keep this records intact for subsequent renewal, or records must be updated very time new cert is requested?

I understand that API-interaction with all different DNS providers is pain, so I'm ready to manually add some records when configuring certs first time (because I must add CAA record anyway), and I think I prefer this scenario (manual records entering) instead of having additional big app that can talk with every DNS provider.

@justdmitry you have to add a txt recorded named _acme-challenge with a value that LE gives you when you request a wildcard cert (this value changes on every renew). It is in fact much the same as the http validation, except you use DNS. So unfortunately doing it manually is going to be bit of a pain (it can be done), but you have to wait sometime before you ask LE to review that you put the challenge up, to ensure that LE's servers get the right response from your DNS server, which makes this process worse than http validation, at least when the file is on the server, you know it is okay to continue.

LE does always contact the authoritative server for the Domain, which is good so you don't have to wait for the DNS change to propagate to any random DNS that they might use. But from my limited experience with the 3 DNS providers I support right now, they all handle DNS updates differently. For all of them there is delay before a newly added record can be queried, there is no for sure way to know how long this delay is, the only reliable way I have found is to do the same test that LE does against all authoritative DNS servers and only when all of them response correctly, is it safe to ask LE to do the validation (LE picks one of your authoritative servers at random).

@sjkp I've got a multi-tenant web app and I want to use a wildcard DNS name for each tenant. That way I can have customer1.mysite.com, customer2.mysite.com, etc, all served from a single web app without needing to create a new web app per customer. I want to avoid all the deployment headaches having individual sites causes, along with not needing to add new DNS records and create certs for every single tenant that I add.

For reference, I don't actually use the site extension. I use @ohadschn's web app renewer, which is built on top of and relies on your great work. The requests on that project for wildcard support are blocked because the support for them isn't in this project. See https://github.com/ohadschn/letsencrypt-webapp-renewer/issues/44 (I use the web job which was very simple to set up and configure).

I wasn't aware of the docker container or of the need to verify DNS txt records but sitting in a loop to check if the DNS servers have been updated sounds like the sort of thing the independent web job can do without needing to be concerned over the 10 minute limit of function apps or the deployment overhead in asking people to add containers to their environment and configuring them.

Also, automating the different DNS providers seems like the sort of thing where you could use a simple plugin model, and build 3 or 4 providers for the obvious ones (e.g. Azure, GoDaddy, DNSimple, etc.) and leave the rest up to the community to contribute based on need.

@rbanks54 thanks for clarifying, then I think it is a matter of documentation and me releasing a new version of the nugets that @ohadschn is using, should be a quick fix.

That would be wonderful! Thanks! 😊