mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
Dropping old ACMEv1 Support? #309
Reference in New Issue
Block a user
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 @lukas2511 on GitHub (Mar 15, 2018).
I'm thinking about dropping ACMEv1 support. Not today, not tomorrow, rather in a few months, with limited support in the meantime.
ACMEv2 has (or will?) become an official RFC and will be the most likely protocol to ever be supported by other CAs, ACMEv1 on the other hand was just really implemented by Let's Encrypt and their own API endpoint will probably be disabled in the foreseeable future.
Dehydrated has quite a bit of code that just deals with ACMEv1 behaviour. A rough count gave me over 150 lines of code (there probably is even more). There are a few open bugs which are only really relevant for ACMEv1 and there were bugs like the recent 301 redirect failure which wouldn't affect ACMEv2 to begin with, so I'm guessing there could be other issues with ACMEv1 and those will be harder to find in the future as the ACMEv1 userbase shrinks.
What do you internet-people think? Is there any good reason supporting it in the long run?
@jobe1986 commented on GitHub (Mar 15, 2018):
As someone who is using dehydrated with the v2 API, I can say thus far I am happy enough with the support that I have no problem with the idea of losing support for v1. That is I have yet to find any reason to revert back to v1.
@txr13 commented on GitHub (Mar 15, 2018):
I guess it largely depends on your definition of "in the long run." I personally wouldn't consider dropping support for a minimum of six months... in the 6-12 month range, I'd probably look at it again and make the decision to drop support at that point.
Of course, anybody who needed v1 support after that could always revert to an old version of the software, too...
@lukas2511 commented on GitHub (Mar 15, 2018):
@txr13 I was thinking about six months, less if Let's Encrypts disables their API endpoint earlier. After all it's basically the only one in existence, so if it gets disabled there isn't much more I can break removing support for it.
And I guess you are right, downgrading always is an option if people really need this and they could always just cherry-pick or easily backport newer features.
@txr13 commented on GitHub (Mar 15, 2018):
Oh yeah, if LE disables their API, you have no reason to wait any longer than that!
@NotActuallyTerry commented on GitHub (Mar 17, 2018):
Considering there is:
I don't see any issue in removing it from current & future code.
If there is any need for a fix with the v1 implementation, it'd be easier to just branch from
fd3fc8aand fix it there than keep support around.@JavaScriptDude commented on GitHub (Mar 27, 2018):
Six months seems reasonable. When you do the switch, users who need v1 can just download a specific version of dehydrated.
@lukas2511 commented on GitHub (Apr 8, 2018):
I decided to close tickets with v1-only minor issues and will no longer work an any bigger v1 improvements. I'll still merge or work on smaller fixes, but nothing that isn't really necessary or would require bigger changes without much benefit for v2 users.
@colin-stubbs commented on GitHub (Apr 9, 2018):
I'd drop it... i spent way too many hours looking at it myself on the weekend, too many hacks required to try and support both :-(
Btw... wildcard certs that are in v02... dehydrated has quite a few points at which the interpretation of the * character goes awry.
How are you considering dealing with it? It seems to me having a configurable wildcard substitution that occurs immediately prior to request signing (ensure *. in CN), challenge deployment (remove *.), etc may be the best way to approach it?
The spec seems to suggest that a number of interactions with the API that have or cause *. to be dropped from the name and a boolean wildcard value set as an indicator that it's a wildcard.
e.g. WILDCARD_SUB='@wildcard@'
So that @wildcard@.domain.tld will be tested sub'ed to *.domain.tld or to domain.tld when necessary.
@lukas2511 commented on GitHub (Apr 9, 2018):
@colin-stubbs there shouldn't really be any problems with the wildcards anywhere in the script and for directory names i'm enforcing aliases to be set so no path with '*' will ever be accessed
@colin-stubbs commented on GitHub (Apr 9, 2018):
Yeah... my bad... and just got around to reading some of the commits and realised you guys have already added a lot of support! Thank you.
@mapreri commented on GitHub (Apr 24, 2018):
@cpu is there any plan within LE for disabling the ACME v1 endpoint?
I'd find nice if you could keep it running for at least the duration of debian 9, so ~2 more years, but I suppose it depends on how burdening it is for you and the amount of requests you'll still receive at that endpoint in the future.
@cpu commented on GitHub (Apr 24, 2018):
There's no plan or specific date decided for disabling ACME v1. ~2 years is a reasonable estimate. It won't be anything that happens suddenly or without a lot of pre-announcement. At this point we have no immediate plans.
@tovine commented on GitHub (May 16, 2018):
Disclaimer: I haven't really read the source code very thoroughly, so forgive me if the question has an obvious answer.
If you remove ACMEv1 support, will dehydrated still support upgrading old configs to the new version? I'm thinking about old installations that have been "set up and forgotten" (as good automation tends to lead to) which suddenly will need to be updated.
@jobe1986 commented on GitHub (May 16, 2018):
I think the discussion is more about the interaction with ACMEv1 servers, as opposed to how dehydrated handles it's own configuration. Therefore I would assume that given what the migration itself actually involves, this shouldn't be an issue.
@lukas2511 commented on GitHub (Oct 20, 2018):
ACMEv1 support in dehydrated will be fully dropped when https://github.com/letsencrypt/boulder/issues/3871 is fully supported in Boulder and on the LE production systems.
I think the change in request handling is a good point to draw a line, especially considering that ACMEv1 should really be considered deprecated by now and with the current dehydrated version being quite stable it's a good fallback for situations where ACMEv1 is still required.
@j-ed commented on GitHub (Jan 21, 2019):
To fully understand the associated impact, I studied a lot of documents on the internet, but I'm still a little bit confused what challenge types are supported by the ACMEv2 protocol.
I'm currently associating ACMEv1 primarily with the challenge type
http-01and ACMEv2 primarily with the challenge typedns-01and the generation of wildcard certificates.Does this imply that the challenge type
http-01cannot be used at all anymore with ACMEv2 or does it only mean that wildcard certificates cannot be generated if you stick tohttp-01?Thank you for shedding some light on this point.
@cpu commented on GitHub (Jan 21, 2019):
You can definitely use http-01 challenges with LE's ACMEv2 API ☑️
You are correct that if you want to issue a wildcard certificate with LE you have to use ACMEv2 and DNS-01 challenges ☑️
@j-ed commented on GitHub (Jan 21, 2019):
@cpu Thank you for your fast reply.
@lukas2511 commented on GitHub (Mar 3, 2019):
ACME v1 support has now been dropped on the master branch.
It wouldn't have been that hard to maintain, but since ACME v2 has been around for quite a while and there is no real reason for anybody to remain on v1 it doesn't make much sense to drag this around with future changes.
@lukas2511 commented on GitHub (Mar 4, 2019):
I was approached by somebody telling me that there actually are Certificate Authorities and resellers out there that implement ACME v1 and not v2. I didn't know about this until today so I didn't recognize that there actually are valid use cases for ACME v1. The removal has been reverted and I'll keep version 1 support around as long as it doesn't become a major inconvenience on bigger code changes in the future.
I've written a bit about the changes between v1 and v2 and the possible future removal of v1 in the documentation so it doesn't become a surprise in the future (see docs/acme-v1.md).
@roelofr commented on GitHub (Jan 17, 2020):
I just received the following mail from Let's Encrypt, indicating the end-of-life for ACMEv1.
@internationils commented on GitHub (Feb 5, 2020):
I've received the same mail... what I haven't been able to figure out is how to get dehydrated to use ACMEv2... there is this in the script:
dehydrated.sh: CA="https://acme-v02.api.letsencrypt.org/directory"...which makes me think that it should be using ACMEv2, but I don't see a protocol version anywhere in the config or logfiles. Could someone please clarify this?
PS apologies for posting on this bug, but not sure where else to post this question.
@mapreri commented on GitHub (Feb 5, 2020):
Check your own configuration file, you might be unwillingly overriding the default.
@internationils commented on GitHub (Feb 5, 2020):
Sigh, thanks @mapreri ... don't know how many times I looked and grepped past that.
@ThomasWaldmann commented on GitHub (Feb 7, 2020):
I also had a bit "troubles" with the v1 to v2 migration.
Had an old dehydrated version (0.4.0) running, so I got the deprecation mail from LE.
Then installed 0.6.5 and tried to find out how to switch from v1 to v2.
No docs about v1 to v2 in the docs folder. Asking myself whether I have to configure something or re-register or whether re-registering could be even harmful?
Also nothing helpful in the example docs (I use defaults for CA and OLDCA and the defaults seem to be correct).
Then manually invoked
dehydrated --cron.It told something about using an v1 account and showed some url with 01 in it, so I thought it still does v1.
It did not say something like "switching from v1 to v2 api now, done" or so.
But a message like this would be useful to not let people in the unclear about whether the deprecation issue is resolved.
So, is all one needs to do installing the new dehydrated code or is there anything else?
@mapreri commented on GitHub (Feb 7, 2020):
it's only about installing a dehydrated that supports v2 (>= v0.6.0) + tweaking the
CAvariable if you are not using the default.@roelofr commented on GitHub (Feb 10, 2020):
Maybe the system should check if you're still using the old V1 API, and print a warning on stderr or something.
But it'd be legacy code on deployment, so I don't know if it's a lot of added value.
@ThomasWaldmann commented on GitHub (Feb 10, 2020):
Of course any change released now won't help all the production systems still running old releases - but that problem is already addressed by the e-mail notifications sent out by letsencrypt.
What needs to be addressed is either clear documentation about v1 to v2 migration (can be very short) or some output by the new installed code which clearly says "using v2 now" so the admins know that they actually solved the issue by just installing the new code.
@brianread108 commented on GitHub (Oct 7, 2020):
Can I ask about the "auto" value for the API parameter? Will it default to API 2 unless there is an existing API 1 certificate?
@roelofr commented on GitHub (Oct 7, 2020):
It looks likeautowill default to v1, but use v2 if a request was previously made using v2.Edit:
autowill default tov1, unless the CA indicates v2 is supported, which is checked by the existence of anewOrderendpoint. (See below)7d3288f428/dehydrated (L532-L535)@brianread108 commented on GitHub (Oct 7, 2020):
Is that what is required? Surely it ought to "default" to v2 and only use v1 if previous, otherwise new certs are going to be presented using v1, which is no longer supported.
@roelofr commented on GitHub (Oct 7, 2020):
You're absolutely right. It does an HTTP request to the CA to figure out what is supported, and checks the returned JSON for
newOrder, what is returned if you use a v2 API (like the default Let's Encrypt URL).So, the
autoparameter means it's determined from the provider, which also meansautorequires an additional HTTP request, but will usually use the most recent version (2, currently).Note that the certificates are stored in the same location, so old v1 certificates are automagically replaced with v2 certificates (v1 and v2 both use standard certificates, so there should be no difference between them for your webserver, unless you're using HPKP, which is deprecated).
Edit: if you insist on using v1 (which is a bad idea), you can change the
CAin your config tohttps://acme-v01.api.letsencrypt.org/directoryand leaveAPIonauto. Switching to v2 is recommended though.@brianread108 commented on GitHub (Oct 7, 2020):
ok, I see, so the check is checking what the CA supports rather than what was used previously. I can see that makes sense, but it is not the use case I am looking for (which is to use v1 if renewing a v1 cert, but v2 otherwise).
@roelofr commented on GitHub (Oct 7, 2020):
To my best of understanding i don't think that's possible natively.
You might be able to use the hook system to check the domain name against a list of known v1 domains, and only deploy those challenges when you're running a v1 update (using two separate configs). But maybe switching the v1 domains over to v2 (if, of course, possible) is the easiest approach.
@lukas2511 commented on GitHub (Dec 11, 2020):
I have no more interest in actively removing ACME v1 support for now. This might change if a version 3 might eventually get introduced. Existing code will remain but will mostly stay untested.