ACMEv2 beta (v0.2.1) now available

[hlandau]

ACMEv2 support has now been merged into master and a beta is available as release v0.2.1. You will need to build this yourself as release automation is being renovated.

This removes and replaces support for ACMEv1. Support for in-place upgrades using existing state directories (/var/lib/acme) is experimental; if you want to try this, just install the new binary and run it. Please make a backup of /var/lib/acme first. Or of course you can start with a fresh state directory.

The repository has moved to hlandau/acmetool from hlandau/acme. This should redirect automatically.

Please report issues on the issue tracker.

[holdenger]

@hlandau Hello, and a big thank you for this. When do you expect release of binaries?

[ewenmcneill]

For anyone else trying to build this from source to test it out, it looks like it'll require golang version 1.9 or higher for the math/bits dependency. So, eg, go version go1.7.4 linux/amd64 in Debian Stretch (9) is too old to build the package (at least automatically). Debian Buster (10) seems to have a new enough go version (go version go1.11.6 linux/amd64) , and that's been backported to Debian Stretch so that's what I ended up using to build (I still have some Debian Stretch systems I need acmetool to run on, and at least by default go builds dynamically linked binaries).

I think the resulting binary is correctly built to be acmetool with ACME API v2, but I've not yet been able to confirm that definitively (it does look like, eg, the right Go dependencies were downloaded; this is building from master which appears to be the latest branch; it looks like acmev2 and dev are behind master at this point, and that the v2 beta support has been merged into master.)

Ewen

vagrant@acmetool-stretch:~$ sudo /bin/sh -c 'echo deb http://deb.debian.org/debian stretch-backports main >/etc/apt/sources.list.d/debian-backports.list'
vagrant@acmetool-stretch:~$ sudo apt-get update
[...]
vagrant@acmetool-stretch:~$ LANG=C sudo apt-get -t stretch-backports install golang-1.11
[...]
vagrant@acmetool-stretch:~$ PATH="/usr/lib/go-1.11/bin:$PATH"
vagrant@acmetool-stretch:~$ go version
go version go1.11.5 linux/amd64
vagrant@acmetool-stretch:~$ echo $GOPATH
/home/vagrant/go
vagrant@acmetool-stretch:~$ cat /etc/debian_version 
9.11
vagrant@acmetool-stretch:~$ git clone https://github.com/hlandau/acmetool.git
Cloning into 'acmetool'...
remote: Enumerating objects: 2797, done.
remote: Total 2797 (delta 0), reused 0 (delta 0), pack-reused 2797
Receiving objects: 100% (2797/2797), 1.07 MiB | 326.00 KiB/s, done.
Resolving deltas: 100% (1736/1736), done.
vagrant@acmetool-stretch:~$ cd acmetool/
vagrant@acmetool-stretch:~/acmetool$ make
    [RELOCATE]    
    [GO-GET]      git.devever.net/hlandau/acmetool
    [DIRS]    
    [DIRS]    
    [GO-INSTALL]      git.devever.net/hlandau/acmetool
vagrant@acmetool-stretch:~/acmetool$ sudo env "PATH=$PATH" make install
    [RELOCATE]    
    [DIRS]    
    [GO-INSTALL]      git.devever.net/hlandau/acmetool
    [INSTALL]     git.devever.net/hlandau/acmetool
vagrant@acmetool-stretch:~/acmetool$ which acmetool
/usr/local/bin/acmetool
vagrant@acmetool-stretch:~/acmetool$ acmetool --version
go version go1.11.5 linux/amd64 gc cgo=true
build unknown
vagrant@acmetool-stretch:~/acmetool$ file `which acmetool`
/usr/local/bin/acmetool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=cc11c0004457975445ab3cc366b2bfc42d448229, not stripped
vagrant@acmetool-stretch:~/acmetool$ ldd `which acmetool`
    linux-vdso.so.1 (0x00007ffc6e7ee000)
    libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f3eda0a7000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3ed9e8a000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ed9aeb000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3eda2ad000)
vagrant@acmetool-stretch:~/acmetool$ 

[SinOJosWeb]

What might the status be of v2. In June of 2020 we will stop allowing new domains to validate via ACMEv1 https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

I have been using ACMEv1 and have had no problems. I like being able to use the redirector. I see that v1 is available via Centos 7 package manager, though I compiled my self. Is there any intentions of providing a v2 binary for Centos 7. Even though there is some time until June 2020. Every time a certificate is added or renewed LetsEncrypt sends me an email reminding me that v1 on June 1 2020 will no longer be allowed.

There has been no activity for a month now. Has the project been put on hold. Should I start looking for something else. There is a long list of v2 releases on the LetsEncrypt website. Everyone else has already moved on to v2. https://letsencrypt.org/docs/client-options/

[mnalis]

@SinOJosWeb ACMEv2 in acmetool seems to be working just fine. I recently compiled latest master branch on Debian Buster (by instructions above for Stretch, just simpler as no backports needed at all), and replaced acmetool binary provided by standard debian package with that. It works just fine. I've also requested ACMEv2-only wildcard certs using DNS hook (homemade for our custom setup for tinydns) and it also works just fine.

So I would say what remains is @hlandau make a release (or at least a release candidate!) soon, so we can go ask package maintainters to make new package (it all takes time!)

[defanator]

Was anyone able to build v0.2.1 on Ubuntu 16.04? Solution from @ewenmcneill does not work unfortunately, libpcap-dev (libpcap0.8-dev actually) on Ubuntu 16.04 does not contain required header (sys/capability.h).

[mnalis]

@defanator Don't know about Ubuntu, but on Debian package is libcap-dev (that is one relating to POSIX 1003.1e capabilities) and not libpcap-dev (which is one about packet capturing for tcpdump and friends).

[defanator]

@mnalis oh sorry, my bad! libcap-dev is the right one there as well. Thank you!

[defanator]

@hlandau v0.2.1 seems to work fine. Hope to expect binaries soon!

[pipiche38]

Any plan to provide a rpm based version for Fedora users ? like what we have for the acmetool on https://copr.fedorainfracloud.org/coprs/hlandau/acmetool/

[SinOJosWeb]

I had no trouble compiling on Amazon AWS Linux 2 AMI. I already had v1 installed via the package manager yum and enabled via systemd running in redirector mode.

Installed: yum install golang libcap-devel

cloned git repository: git clone https://github.com/hlandau/acmetool.git

enter ~/acmetool directory run "make" wait for it to finish: systemctl stop acmetool-redirector.service mv /var/lib/acme ~/acme-v1 mv /bin/acmetool ~/acmetool-v1 cd ~/acmetool/bin cp acmetool /bin systemctl start acmetool-redirector.service acmetool quickstart acmetool want domainname.com

I run haproxy did not have to change any settings. Rebooted and it works. Now simply wait to renew time, and hopefully it will renew without any errors.

[tomwaldnz]

On Amazon Linux 1 I get this error when trying to build. I'll just wait for the binary.

git config --global http.followRedirects true
git clone https://github.com/hlandau/acme
make
        [RELOCATE]
        [GO-GET]          git.devever.net/hlandau/acmetool
# gopkg.in/hlandau/svcutils.v1/caps
src/gopkg.in/hlandau/svcutils.v1/caps/caps-linuxc.go:9:10: fatal error: sys/capability.h: No such file or directory
 #include <sys/capability.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [.gotten] Error 2

[pipiche38]

seems same as https://github.com/hlandau/acme.t/issues/1

[pipiche38]

I'm newbie on GO so probably I'm missing something:

Fedora 31 go version go version go1.13.6 linux/amd64

 make
    [RELOCATE]
    [GO-GET]      git.devever.net/hlandau/acmetool
# git.devever.net/hlandau/acmetool/storageops
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:76:49: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.AssistedRegistration
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:437:48: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.AssistedRegistration
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:456:41: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.Order
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:456:58: cannot use &orderTpl (type *"github.com/hlandau/acmeapi".Order) as type *"gopkg.in/hlandau/acmeapi.v2".Order in argument to solver.Order
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:461:37: not enough arguments in call to r.store.ImportCertificate
    have (string)
    want (*storage.Account, string)
make: *** [Makefile:76: .gotten] Error 2

[slashr]

I've got the same (similar?) problem as @pipiche38

root@ip-172-31-12-130:/home/admin/acmetool# make
    [RELOCATE]
    [GO-GET]      git.devever.net/hlandau/acmetool
package github.com/hlandau/acmetool/cli
    imports context: unrecognized import path "context"
package github.com/hlandau/acmetool/cli
    imports github.com/coreos/go-systemd/dbus
    imports github.com/godbus/dbus/v5
    imports github.com/godbus/dbus/v5
    imports github.com/godbus/dbus/v5: cannot find package "github.com/godbus/dbus/v5" in any of:
    /usr/lib/go/src/pkg/github.com/godbus/dbus/v5 (from $GOROOT)
    /home/admin/acmetool/src/github.com/godbus/dbus/v5 (from $GOPATH)
package github.com/hlandau/acmetool/cli
    imports github.com/coreos/go-systemd/dbus
    imports github.com/godbus/dbus/v5
    imports github.com/coreos/go-systemd/unit
    imports github.com/hlandau/goutils/os
    imports github.com/hlandau/xlog
    imports github.com/mattn/go-isatty
    imports golang.org/x/sys/unix
    imports math/bits: unrecognized import path "math/bits"
Makefile:76: recipe for target '.gotten' failed
make: *** [.gotten] Error 1

[ewenmcneill]

In https://github.com/hlandau/acmetool/issues/322#issuecomment-581110939 @tomwaldnz wrote:

On Amazon Linux 1 I get this error when trying to build. I'll just wait for the binary.

@tomwaldnz sys/capability.h is part of libcap; do you have that installed? (Not libpcap for packet capture, but libcap for Linux Capabilities). Eg, https://packages.ubuntu.com/search?searchon=contents&keywords=sys%2Fcapability.h&mode=exactfilename&suite=eoan&arch=any turns it up in libcap-dev on Ubuntu Linux.

It looks like Amazon Linux is based on a RPM distro, and searching through, eg, Packages in Amazon Linux 2018.3 it looks like libcap is provided by libcap-2.16 or similar (seems to be the same for Packages in Amazon Linux 2016.3 too).

Did you install libcap-2.16 before you started trying to go build acmetool?

(According to https://github.com/hlandau/acme.t/issues/1 mentioned at https://github.com/hlandau/acmetool/issues/322#issuecomment-581117404 above, this is in the README, but it's just mentioned in the text before the example on how to build, rather than as an obvious "install this first" step.... :-) )

Ewen

[sjamaan]

A binary in the package repos would be great, especially if you see how many people are having trouble compiling it.

[jwkohnen]

For folks who come here by Google search etc and have trouble building this binary: Go modules solve all build issues because @equinox0815 already went through the trouble for us to pin down dependency version that actually work. See https://github.com/hlandau/acmetool/pull/326

A small recipe for Debian based systems, off the top of my head, assuming you already checkout this repository:

sudo apt install libcap-dev
git remote add equinox0815 https://github.com/equinox0815/acmetool.git
git fetch --all
git checkout -b equinox0815/acmetool equinox0815/acmetool
go diff origin/master   # check if you're happy with the changes
go build
sudo dpkg-divert --add --rename /usr/bin/acmetool
sudo cp acmetool /usr/bin/acmetool

Don't ever try to run the Makefile, it will ruin your day.

[jwkohnen]

@hlandau please please merge in #326. <3

[k3a]

You may also try the old way of getting Go software (run outside any go module):

go get -u github.com/hlandau/acme/cmd/acmetool

That should produce the binary based on master branch.

[lightdot]

Just a heads up, builds just fine with mock on CentOS 8 with #326 included.

Build dependencies are simply golang, git and libcap. All in all, a really simple and straightforward .spec is all acmetool needs.

[pipiche38]

What is the process to move from V1 to V2 ? does reconcile is enough ?

[dsadinoff]

Just a heads up, builds just fine with mock on CentOS 8 with #326 included.

Build dependencies are simply golang, git and libcap. All in all, a really simple and straightforward .spec is all acmetool needs.

Also success wtih same approach on CentOS 7.

Upgrade seamless so far, with no issues.

[backstube]

What is the process to move from V1 to V2 ? does reconcile is enough ?

Same question here.

We keep getting nudged by Let's Encrypt to migrate "to an ACMEv2 compatible client" before June. We have latest acmetool (as of today) running doing its job just fine (apparently). But there's no clue if it does work on v2 nor if it is capable of v2. Only git logs tell that yes, there is v2 present.

What needs to be done to convince acmetool using v2 instead of v1?

Unfortunately, the User's Guide doesn't mention v2 at all. My suggestion would be to add a small paragraph covering this issue.

Thanks for this tool that served us many years just fine!

[backstube]

This is what LE keeps alerting via mail: User agent: acmetool acmeapi Go-http-client/1.1 freebsd/amd64 Seems like we're still on v1.1 ...

[Mrten]

just a small question for those that keep being reminded to upgrade (haven't tried myself yet): have you changed the URL for the endpoints?

This is the old one:

request:
  provider: https://acme-v01.api.letsencrypt.org/directory

I'm supposing this should be changed to -v02.

[backstube]

just a small question for those that keep being reminded to upgrade (haven't tried myself yet): have you changed the URL for the endpoints?

I have not.

This is the old one:

request:
  provider: https://acme-v01.api.letsencrypt.org/directory

I'm supposing this should be changed to -v02.

On FreeBSD this file is /var/lib/acme/conf

But I doubt this would help much. The host acme-v02.api.... only is an alias mapping on prod.api.letsencrypt.org, as well as acme-v01.api.... is.

So what needs to change is acmetool using the new protocol. Today, unfortunately there is no hint in the docs how to do this. Precisely, there is no mention of "v2" altogether.

So my best guess is that it's in the works (most recent commit is tagged as beta) and when leaving beta phase the user's guide and man page will be updated as well.

[pipiche38]

But I doubt this would help much. The host acme-v02.api.... only is an alias mapping on prod.api.letsencrypt.org, as well as acme-v01.api.... is.

Are you sure it is an alias ? From what I see https://acme-v02.api.letsencrypt.org/directory is different than https://acme-v01.api.letsencrypt.org/directory. Basically the new-authz/new-cert/new-reg/revoke-cert point on different URL.

[backstube]

Are you sure it is an alias ?

All I did is this:

$> host acme-v01.api.letsencrypt.org
acme-v01.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address 172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address 2606:4700:60::f53d:5624:85c7:3a2c
$> host acme-v02.api.letsencrypt.org
acme-v02.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address 172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address 2606:4700:60::f53d:5624:85c7:3a2c

And DNS-wise it looks pretty much identical to me. Sure the web server can branch out via SNI.

[Mrten]

I'm thinking that you could differentiate on prod.api.letsencrypt.org between acme-v01 and -v02 via Host: headers, anyway, I'll try and report back.

[backstube]

I'm thinking that you could differentiate on prod.api.letsencrypt.org between acme-v01 and -v02 via Host: headers, anyway, I'll try and report back.

Yes, exactly. That's what I was refering to as Server Name Indication (SNI).

[Mrten]

This says:

This is a non-backward-compatible version of the API, so ACME v1 clients
(almost all clients available today) will not work with the ACME v2 endpoint. 
Existing clients will need code changes and new releases in order to support
ACME v2.

I've just changed the provider to the v02 staging API and after running the beta of acmetool I've got a bunch of certificates now in a (before the run cleaned up) /var/lib/acme. I think this verifies that the beta of acmetool talks v2 of the protocol without any additional config changes.

I have both HTTP and DNS (ACMETOOL_IS_DNS=1 via dns.hook) challenges and everything /looks/ complete, so I'd say that the beta works as intended. @hlandau please take note :)

[pipiche38]

@Mrten so you did change the /conf in order to replace v01 by v02 ?

[Mrten]

acme@acme:/var/lib/acme$ cat conf/target
request:
  provider: https://acme-staging-v02.api.letsencrypt.org/directory
[...]

[mnalis]

I simply started acmetool quickstart and chose Let's Encrypt (Live v2).

If everything is migrated correctly (and on most sites it does), acmetool status | grep v01 should not display anything. If it does, you will need to more manual fixing. I usually do acmetool cull followed by grep -r v01 /var/lib/acme to identify files which need changing provider URI from v01 to v02

[pipiche38]

I simply started acmetool quickstart and chose Let's Encrypt (Live v2).

Can you do an àcmetool quickstart`while you have already an existing setup ?

[mnalis]

@pipiche38 yes, acmetool quickstart is how I did it on dozens of servers. It will not damage the existing domains (desired, keys, certificates etc). You will have to answer few questions again though (same as you did first time you installed it - which ACME method you use, path to webroot if used, notification email).

Of course, it is always good idea to backup /var/lib/acme first before any changes (generic recommendation - I myself did not have a need for it yet).

[xbeaudouin]

Anybody can update acmetool on FreeBSD ? June 2020 is comming fast and my tentatives to tweak the freebsd ports has fails :(

[xbeaudouin]

Okay took one day to make that, but I have finaly one FreeBSD port working... Will do a PR to fix that...

[mnalis]

Just a heads up to people that they should check that upgraded acmetool does not try to use old API:

acmetool status | grep -i v01

should return empty output. Also, to be completely sure, after that check above to make sure you're not using old API, one may want to try to force a certificate reissue for one of their certificates:

touch /var/lib/acme/live/www.example.com/revoked
acmetool reconcile

[ewenmcneill]

Replying to myself from https://github.com/hlandau/acmetool/issues/322#issuecomment-566834656:

I think the resulting binary is correctly built to be acmetool with ACME API v2, but I've not yet been able to confirm that definitively

FTR, I've now put the binary I built in https://github.com/hlandau/acmetool/issues/322#issuecomment-566834656 into production, and it seems to work with both the ACME v2 staging API (https://acme-staging-v02.api.letsencrypt.org/directory) and the ACME v2 production API (https://acme-v02.api.letsencrypt.org/directory).

To switch over, I updated the binary (using Debian update-alternatives to point at the new one in /usr/local/bin/acmetool), updated the provider in /var/lib/acme/conf/target to the ACME v2 API, then:

cd /var/lib/acme
mkdir old old/accounts old/certs
mv accounts/* old/accounts
mv certs/* old/certs
acmetool status
acmetool reconcile
acmetool status

The acmetool status complained of a bunch of broken links (certificates gone), and apparently removed them (I think those were in the keys directory), and then the acmetool reconcile generated a new account (only possible with the v2 API now I believe), and created new TLS keys/certificates.

If I were doing it again, especially with only a few domains, then it might be better to just move the entirety of /var/lib/acme aside, and set it up again. (I did that for testing with the staging API, and it didn't take very long to get to testing one domain.)

So I think the main "production ready" thing this new acmetool needs is an official/binary release that makes it easier for people to install. It'd definitely help if that was done before June.

Ewen

[kontextbewusst]

Can anyone provide working build directions for Ubuntu 18.04? I have tried all the suggestions in this thread and none of them worked. Would love to get this working before the deprecation deadline for v1 hits. Thank you!

[k3a]

In the latest Ubuntu docker image (18.04.3 LTS) it is a one-liner....

apt update && apt install -y golang git libcap-dev && go get -u github.com/hlandau/acme/cmd/acmetool && ~/go/bin/acmetool help

[kontextbewusst]

@k3a thank you, but the go get results in the following:

root@castor:~# go get -u github.com/hlandau/acme/cmd/acmetool
package github.com/godbus/dbus/v5: cannot find package "github.com/godbus/dbus/v5" in any of:
    /usr/lib/go-1.6/src/github.com/godbus/dbus/v5 (from $GOROOT)
    /root/go/src/github.com/godbus/dbus/v5 (from $GOPATH)
package math/bits: unrecognized import path "math/bits" (import path does not begin with hostname)
package context: unrecognized import path "context" (import path does not begin with hostname)

[k3a]

Go 1.6 is probably way to old. You can compile it in the latest Ubuntu docker image like this:

# run interactive docker
docker run --rm -it --name ubuntu ubuntu
# in the opened shell, run the update and compilation commands
apt update && apt install -y golang git libcap-dev && go get -u github.com/hlandau/acme/cmd/acmetool
# from the host computer (outside docker container), copy compiled acmetool
docker cp ubuntu:/root/go/bin/acmetool ~/acmetool
# profit!
~/acmetool help

You can also add CGO_ENABLED=0 before "go get" to compile static binary (without any dependency to system libraries).

I compiled both for you today using the mentioned steps https://drive.google.com/drive/folders/1_Tn6AMtnnmTgbXCweJ4U9jftyKbMRsk- hope it helps. Static version should work everywhere. But please note that it is the latest version made from "master" branch. It should be considered experimental. It should work, though. Back up you /var/lib/acme folder just in case.

[vsajip]

FYI I was able to build acmetool locally using Christian Pointner's repository as mentioned above - thanks to @jwkohnen for the pointer. Of course it's not an official release, which would be ideal.

[asalmela]

Ubuntu 20.04 has 0.2.1 packaged, it'll probably install on 18.04 without issues too.

https://launchpad.net/ubuntu/+source/acmetool

[CL-Jeremy]

@asalmela It does. I initially wanted to build a package for bionic and after installing tons of gopkg-packages I realized just how outdated and full of security vulnerabilities those dependencies are. Installing the self-contained binary package from the newer distro is the way to go here.

[ewenmcneill]

Go 1.6 is probably way to old. You can compile it in the latest Ubuntu docker image like this:

Go 1.6 is definitely too old. As I said in https://github.com/hlandau/acmetool/issues/322#issuecomment-566834656, Go 1.7 was too old and Go 1.11 was new enough. IIRC (it's been about 4 months since I dug into this) either Go 1.9 or Go 1.10 was the minimum for maths/bits to be included in Go (which is a dependency of one of the libraries used).

So Debian Buster, Ubuntu 20.04 (maybe Ubuntu 18.04?), sort of age Linux distro/go versino would be needed to build this software. Ie, at least 2018, maybe 2019 or later Linux distro.

(I did build it for Debian Stretch, but had to install a Go backport to do so.)

Ewen

[CL-Jeremy]

So Debian Buster, Ubuntu 20.04 (maybe Ubuntu 18.04?), sort of age Linux distro/go versino would be needed to build this software. Ie, at least 2018, maybe 2019 or later Linux distro.

In this case Linuxbrew may be a brilliant distro-agnostic solution. Had a lot of good time with it while I was working on shared computers without root permissions (partially because I'm mainly a Mac Homebrew user). Updates typically roll out pretty fast. Plus, old Go dependencies aren't usually necessary for these standalone programs and introduce only security risks, so as mentioned earlier, direct backporting isn't really a good solution.

[samm-git]

I just did a blogpost about migration to v2 api using acmetool - https://smallhacks.wordpress.com/2020/05/06/migration-to-lets-encrypt-v2-api-with-acmetool/

@hlandau thank you for your work!