mirror of
https://github.com/ridercz/AutoACME.git
synced 2026-04-25 07:05:55 +03:00
[GH-ISSUE #17] AutoACME v2 plans and discussion #16
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AutoACME#16
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ridercz on GitHub (Mar 15, 2018).
Original GitHub issue: https://github.com/ridercz/AutoACME/issues/17
Current (1.x) version of AutoACME is using ACME v1 protocol. Let's Encrypt now launched in production the ACME v2 and although there are no plans to retire v1 in foreseeable future, I'm starting to work on AutoACME v2 as well. This issue is a point for discussion about design and features.
What will remain:
What will change:
The main feature, and also the main problem, is the SAN certs support. I avoided it in the current version for many good reasons. The rate limiting LE started to impose some time ago is a game changer, though. I'm not sure about how to approach it. There are two ways I'm thinking about right now.
First is fully manual approach. AutoACME would allow you to attach the alternative host names to parent one and would not do any kind of automatic grouping.
Second is some kind if intelligence. Ie. AutoACME will try to group host names by domain (ie.
www.example.com,example.comandshop.example.comwould be grouped together with the shortest variant as common name). It could also group multiple TLDs (example.com,example.netandexample.cz), but it's unnecessary from the rate limiting standpoint (the most crtitical limit is the 20 certificates per domain limit) and also there are some ugly exceptions to be taken into consideration (ccTLDs who don't let directly register a subdomain, but add additional suffix, likeexample.co.uk).@Timo-Breumelhof commented on GitHub (May 24, 2018):
Do you have a planning for this / an idea of a release date? :-)
@avonwyss commented on GitHub (May 29, 2018):
I'd like to see wildcard support, and it may not be as complicated as it seems. The DNS challenge can be redirected to any other record by the means of a CNAME entry (this is supported and works). Therefore you can apply a similar "catch-all technique" like you currently do for the HTTP challenge, you just need control over one (sub)domain which is used as container for all DNS challenges like so: *.example.org requires a DNS challenge _acme_challenge.example.org, which can be a CNAME to something like example.org.acme.company.org in a DNS zone acme.company.org which is controlled by AutoACME (by means of command line commands like
dnscmd, or even better a self-hosted DNS server in AutoACME itself).If you merge my PR (which is a first step towards adding another challenge type) and implement ACME v2 protocol I'd be happy to try and implement the DNS challenge part.
@avonwyss commented on GitHub (Nov 28, 2018):
The changes in #33 addresses some of the v2 topics.
@NenoLoje commented on GitHub (Jan 30, 2019):
Any plans for a release of the ACMEv2 version?
@avonwyss commented on GitHub (Jan 31, 2019):
@NenoLoje Releases are in @ridercz responsibility. In the meantime you could build it yourself, my version with DNS, SAN and wildcards has been running successfully for weeks now in my environment.
@bbakermmc commented on GitHub (Sep 3, 2019):
@ridercz Is wildcard support added? The read-me says no, but it looks like in Nov you added it...
@avonwyss commented on GitHub (Sep 3, 2019):
@bbakermmc Yes, wildcard has been merged into AutoACME. Wildcard however works only with DNS, please have a look at this wiki page:
https://github.com/ridercz/AutoACME/wiki/AutoACME-in-a-web-farm-environment#operation-with-dns-challenge
These changes were contributed by me and @ridercz may not yet found time to update the website and readme. ;)
@RyanDansie commented on GitHub (Jan 17, 2020):
Any chance of having a new release to include this at some point soon? Lets Encrypt will stop issuing new certificates in less than 6 months and it would be a shame for this great tool to become obsolete.
@JashanChittesh commented on GitHub (Jan 17, 2020):
I have also received that email from letsencrypt.org, and currently, AutoACME is not listed as compatible client: https://letsencrypt.org/docs/client-options/
There were a few releases since 2018-11-28, where #33 was merged, so I'd assume that the current release (1.6.2 from 2019-03-14) should supports ACMEv2. I just updated (from 1.5.3), so hopefully all goes well.
@avonwyss Can you confirm? Also, with letsencrypt.org having sent out this message probably to everyone using an older version of AutoACME, it might be a good idea to change the main readme and, if possible, the release comments. And maybe have AutoACME added back to the official client list ;-)
@avonwyss commented on GitHub (Jan 17, 2020):
@JashanChittesh @RyanDansie The current release is actually using the ACMEv2 protocol (and it also supports DNS-based wildcard and SAN requests). However, it is not a .NET Core rewrite and it does not handle revocation, so it is still a 1.x version (but this is the AutoACME version, not the used ACME version). BTW I have not received an e-mail myself even though I received LE certificate reminders in the past, so I think this is indeed only sent to users who are still using an old, pre-1.6.0 release of AutoACME.