Support wildcard certificates with ACMEv2

[raqbit]

On January 27 letsencrypt will make star certificates fully available via the ACME v2 protocol.
Are you planning on adding support for this?

[buchdag]

Wilcard certs will require dns-01 challenge and simp_le only support http-01, so they won't be available through letsencrypt-nginx-proxy-companion.

zenhack/simp_le#101

[raqbit]

Well that's a bummer. As Python-acme is part of certbot I'd guess they will implement v2 soon-ish, and then simple_le will able to support it as well in the future. Anyways, thanks!

[buchdag]

Unfortunately it's not as simple as that, let me clarify : support for ACME V2 will be implemented in simp_le, but dns-01 challenge won't.

dns-01 challenge is not new or specific to ACME v2 and the original simp_le developer (@kuba) made the explicit choice to limit simp_le to http-01 challenge from the beginning (you can see it in the manifesto, point 3).

[raqbit]

Oh, I see. Thanks for helping :)

[buchdag]

@raqbit I'm re-opening so the issue and the reason why we won't (/ can't) support wildcard certs have better visibility.

[almereyda]

Please see zenhack/simp_le#101 (comment) for updates on the upstream issue, since the v2 endpoint has finally been released to production.

[buchdag]

@almereyda as told in my first message on this issue and on the simp_le issue you mentioned, wilcard certificates requires dns-01 challenge support, which is absent from simp_le (and there are no plans to add it).

This is not the same thing as (or related to) Acme v2 support.

[Dragnucs]

I am curious. Can't simp_le be replaced with another components that could handle dns-01 challenge? If not, what are our options? Can't we hack the configuration a bit on our end to support it?

[buchdag]

It could, letsencrypt-nginx-proxy-companion is pretty much "just" bash automation around simp_le and nginx-proxy, there is nothing preventing someone from re-writting it to use another ACME client and provide additional features. As usual with small open source projects the only real issues are the amount of work necessary and the time it takes.

I've been thinking for a while about doing a fork of this project using certbot instead of simp_le but it's pretty far from a drop-in replacement as the two behave in very different ways. I lack the time to do more than experiment a bit with the idea once in a while.

As for other options, the most serious is probably switching to a bigger project like https://github.com/containous/traefik

To be honest I have my doubts about the long term viability of the nginx-proxy / docker-gen solution as it's now extremely hard to get contributions merged to those projects (mostly due to the fact that their creator is very busy working at influxdb, I guess. That's understandable).

[Dragnucs]

@buchdag thank you for your reply.

[almereyda]

The simp_le issue mentions that they are planning to support the DNS-01 challenge soon'ish.

…

On 15 March 2018 at 10:51, Dragnucs ***@***.***> wrote: @buchdag <https://github.com/buchdag> thank you for your reply. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABka_GISKEcuTX9F-FpUc2P_lNQPU3rIks5tejmzgaJpZM4RmAk2> .

[buchdag]

Errr no it does not.

We (zenhack and I) said on that issue that ACME v2 support is planned (we said nothing about when, and it might turn out to be harder than expected) and that dns-01 is out of scope.

Again dns-01 challenge is required to obtain a wildcard certificate through the Let's Encrypt ACME v2 endpoint, but they are not one and the same thing: implementing ACME v2 does not imply implementing dns-01 challenge at all.

[evertramos]

@buchdag Thanks for your contribution!!! Traefik works really fine with it!!! I am doing some tests around it and it seems pretty stable as well. Since I have a couple servers running this repo It will take a couple months to release something usefull, but thank in advance!

[BirkhoffLee]

Maybe give users a hint in https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion/blob/master/app/letsencrypt_service#L106 when they receive this useless error? Like adding the link to this issue in the output. We expect this to work, but it actually fails

nginx-letsencrypt    | /etc/nginx/certs/*.birkhoff.me /app
nginx-letsencrypt    | Creating/renewal *.birkhoff.me certificates... (*.birkhoff.me)
nginx-letsencrypt    | /usr/lib/python2.7/site-packages/acme/jose/jwa.py:110: CryptographyDeprecationWarning: signer and verifier have been deprecat
ed. Please use sign and verify instead.
nginx-letsencrypt    |   signer = key.signer(self.padding, self.hash)
nginx-letsencrypt    | ACME server returned an error: urn:acme:error:malformed :: The request message was malformed :: Error creating new authz :: W
ildcard names not supported

It actually took me a while to figure out what happened. Thanks for the nice work tho

[buchdag]

@BirkhoffLee "expect this to work" "useless error" ... nice tone there.

BTW the "useless error" actually comes from simp_le, not from this container's code.

[BirkhoffLee]

I’m sorry, I didn’t mean to say that. I’m not a native English speaker so.. haha I’ll try to dig into the code and see if I can add a hint to the error when I have free time :) Sorry again for what I said, and thanks to everyone for the contribution to the awesome project!

…

On Wed, Apr 25, 2018 at 2:23 PM Nicolas Duchon ***@***.***> wrote: @BirkhoffLee <https://github.com/BirkhoffLee> "expect this to work" "useless error" ... nice tone there. BTW the "useless error" actually comes from simp_le, not from this container's code. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxUf9jjsuyAqnU95EOfvJuJM1sQCOPEks5tsBZ9gaJpZM4RmAk2> .

[buchdag]

My bad, I did not realize you were a non native english speaker. 😅

You're right with the fact that some warnings about unsupported features (as of now) like ACME V2 endpoints and wildcard certificates should be added. I'll try to add this to dev this week.

[BirkhoffLee]

Thanks 😄

…

On Wed, Apr 25, 2018 at 2:50 PM Nicolas Duchon ***@***.***> wrote: My bad, I did not realize you were a non native english speaker. 😅 You're right with the fact that some warnings about unsupported features (as of now) like ACME V2 endpoints and wildcard certificates should be added. I'll try to add this to dev this week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxUf2i0qWuzak52cgRseaj98kZ9vYikks5tsByhgaJpZM4RmAk2> .

[buchdag]

A pre-release with ACME v2 support is available as tag v1.12-rc.1. I can't guarantee this is fully production ready yet.

This is just part of the upcoming switch to ACME v2 protocol prior to the November 1st deadline I alluded to in my previous message, it does not bring support for wildcard certificates.

I had way less free time than expected since the end of July, so things are going rather slowly 😒

[nffdiogosilva]

Just like to say that I've just tested the tag v1.12-rc.1 and according the logs, it generated the certificate with no hiccup whatsoever. So far so good.

Congratulations on this amazing tool to automate production environments!

[stradarius]

Confirm that v1.12-rc.1 works with ACME v2 . I needed to upgrade:
While it was possible 2 days ago to create certificates with ACME v1, today I was not able to create any new certificate with ACME v1 - maybe duedate is not really beginning of november?

[janus-reith]

See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/3

We will be beginning brown-outs for new ACME v1 registrations for the production environment for the following dates of this year:

October 10th to October 11th
October 16th to October 18th
October 31st onward
We will be permanently disabling new ACME v1 registrations in the production environment on October 31st.

I can confirm that as of today ACMEv1 was not supported for me anymore:
ACME server returned an error: urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.

Upgrading to v1.12-rc.1 worked and certificates were created properly.

[buchdag]

ACME v2 support has been merged to master in #590

latest is now compatible with ACME v2 and tagged version v1.12 is now available.

stable should be updated to v1.12 by the end of the month.

dev has been rebased with master and supports ACME v2 too.

[kopax]

Hi, I am discovering this project. I see why the issue has been reopened but I also see there is a v1.12 solution for it. Is this finally solved? Thanks for sharing!

[buchdag]

Quoting myself:

This is just part of the upcoming switch to ACME v2 protocol prior to the November 1st deadline I alluded to in my previous message, it does not bring support for wildcard certificates.

[benben]

great work. thank you! Is there a way to support your work with a donation?

[almereyda]

Now following suite with the release of v2 through #510 and #719, it appears even more possible to use dns-01 ACME v2 challenges with the companion.

In #510 (comment) @pini-gh communicated the existence of a fork --- that happens to find itself at https://github.com/pini-gh/docker-letsencrypt-nginx-proxy-companion in opposition to the link provided there --- that implements the requested change here. See the comparison in v2.0.1...pini-gh:dns-01-challenge

Would this deem a suitable moment to issue a Pull Request from this PoC and test and extend it against the maintainer's expectations?

[buchdag]

@almereyda as usual I'd really like to give users a roadmap and stick to it, but you saw how well it went the last time I tried that.

Things I can say for now:

• yes, now that Switch to acme.sh #510 / Replace simp_le with acme.sh #719 are done, dns-01 challenges support will be worked on
• there is some CI/CD and code refactoring work that I want to do before that
• also, improvements on logging and debugging
• I'll certainly start with @pini-gh fork and work with him on this if he wants to and has time to spare
• it will probably be way harder to create a working integration test for this feature than the feature itself

[MohammedNoureldin]

Hello, any news regarding DNS challenge support?

[xicond]

Is there a way to customize executed acme.sh when I want to do wildcard with dns-01 challenge, I'll use if-else per domain to append TOKEN and change to dns-01 challenge

[Miladiir]

Hi, what about #916, any plans to merge it?

[Hexalyse]

Bumping this issue since not a single comment has been posted in response to the PR #916 which seems to implement wildcard certificates (albeit only supporting Cloudflare if I understood correctly).

Is it planned to be merged ? Or is this feature simply not planned to be implemented in acme-companion for now ?

[daweedm]

@Miladiir @Hexalyse the PR #916 is unfortunately too much specific to cloudfare (because it's checking for the existence of CF_Token environment variable).

I have created a PR (#1022) for adding generic support for DNS challenges which is fully working for "non-wildcard" domains with minor changes to the code base and being not specific to any provider.

Based on what I have read in the #916 , the PR #1022 may not require a lot of additional work in order to support wildcards domains, because wildcard certs are issued based on DNS challenge : I think it only require to update the functions.sh as it's done in #916, but to be confirmed by @buchdag

[PedroVallejo5]

Are there any updates on this? This feature is gonna help us a lot

[aaccioly]

If anyone is looking for a working alternative, here's an example of how to combine nginx-proxy with adferrand/dnsrobocert: Script to deploy certificates generated with DNSroboCert to nginx-proxy. It's working very well, feel free to use it in any way that you see fit.

[Cilenco]

For anyone searching for wildcard certificate support in nginx-proxy:

I've created a docker image which is based on go-acme/lego and works perfectly well with nginx-proxy.
It supports all of their DNS providers and auto updates the certificates using cron before they get invalid.

[necaran]

Here is another workaround, using acmesh-official/acme.sh to work with nginx-proxy.
It is extremely lightweight since the container of acme.sh takes only about 1 MiB of RAM (as shown by docker stats).