End of Life Plan for ACMEv1

[ronnyadsetts]

Now that the ACME protocol is an IETF standard[1], Let's Encrypt have announced an end-of-life plan[2] for the ACMEv1 endpoints. The first date of significance is Nov 2019 when new account creation will stop working.

I'd really like to continue using acme-tool as it suits my workflow perfectly.

Is anyone working on a fork to get the ACMEv2 protocol stuff to completion?

Have people migrated to different tools, if so what?

Thanks.

[1] https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html
[2] https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

[metaminimalist]

I'm about to switch to lego (lego).
I rather wanted to use acme-client-portable a.k.a. letskencrypt (no typo), but it seems I was late for the party: that project is dead/readonly (the linux-port, the BSD original now lives in openBSD).

lego is also used by caddy-server (as a library, that is how I found it) and its also a single go-lang binary.

I've converted my own private VPS to lego last weekend (not necessary in the most efficient way, I reinstalled everything new, because also switched DNS and VPS provider, changed registration email address, used the newest OS release and now use RSA 4096bit keys for https, postgres and ). So I basically unwanted my certificate at the old server, switched DNS to the new server, and ordered a new and longer one at the new server.

It has no quickstart feature, but then.. before choosing the next acme client I went through ACME manually, so I now know what happens behind the curtains.

Do your testing with a dedicated testing domain! My old caddyserver install once had a root-owned, non-removable pid file which made systemd restart caddy about a dozend times a second (trying to renew the cert every time) and in no time I was blocked (rightfully so) by LE. Which is also the reason why I do want seperated programs for serving the web and ACMEing.

[asalmela]

@ronnyadsetts, there is acmev2 branch mentioned in issue #305

[ronnyadsetts]

@metaminimalist Thanks, lego looks interesting.

@asalmela Thanks, yes, I know about the branch but the very first bullet point of that link states "It is very alpha" which scares me a little. :-).

[cpu]

One other date to be aware of is the intended deprecation of unauthenticated GET requests for ACME v2: Nov 1st, 2019.

Without modification I think the acmev2 branch will break after this date. Spot-checking the underlying acmeapi lib being used by the acmev2 branch shows it is using GET requests to fetch order details (as one example): https://github.com/hlandau/acmeapi/blob/87987748f12bcd6f0570f59604a6279e5277e664/api-res.go#L265

[infoman]

I also just received this from LE:

Hello,

Action is strongly recommended to prevent problems with your Let's Encrypt
certificate renewals.

A client you have used to access the Let's Encrypt API in the past 60 days has
identified itself (its "user agent") as "Go-http-client". This is a generic
name for the underlying library that the client uses, which does not give us
enough information to track and resolve problems with the client or clients.

Within the past 60 days, our /new-reg API endpoint received about 104
requests from the IP address xxxxx .

We've found that in most cases, the client is an older version of kube-lego or
cert-manager. We've worked with Jetstack, the maintainer, to release an update
to each of those packages. If you are using either, we recommend upgrading to
the latest version of cert-manager.

We would like to help fix clients that send our API many requests that will
never complete successfully. It's possible that in the future, we may need to
block these clients in order to protect our resources. By fixing or upgrading
your client, you can help avoid problems with your certificate renewals.

[Mrten]

same mail here

[jvw1954]

Same mail here

[bago]

Same here. I just opened a topic in the Help section of their community forum:
https://community.letsencrypt.org/t/action-required-lets-encrypt-client-problem-acmetool/94193

UPDATE: the email was sent by mistake. We only have to care about ACMEv1 deprecation (deadline june 2020 for new domains registration / june 2021 no more renewals)

[ndilieto]

I rather wanted to use acme-client-portable a.k.a. letskencrypt (no typo), but it seems I was late for the party: that project is dead/readonly (the linux-port, the BSD original now lives in openBSD).

I used acme-client-portable for some time but due to lack of support for ACMEv2, I wrote my own in plain C: check https://github.com/ndilieto/uacme if you're interested.

[holdenger]

@metaminimalist @ronnyadsetts just a note to lego - It doesn't support multiple hostnames in one certificate.

[haraldkoch]

@holdenger yes - it does. https://controlledflight.ca/ was obtained using lego.

[hlandau]

A beta of support for ACMEv2 is now available, see #322.

[pipiche38]

Unfortunatly this beta does not compile !

[equinox0815]

@pipiche38 have you tried using my patch #326 ?

[pipiche38]

@pipiche38 have you tried using my patch #326 ?

Thanks ! it works