ACMEv2 beta (v0.2.1) now available

[hlandau]

ACMEv2 beta (v0.2.1) now available

[holdenger]

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

[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!)

[SinOJosWeb]

I get that some of you are a bit frustrated due to having to compile acmetool your self. While others have taken compiling acmetool in stride. I develop with Gentoo Linux which is a compiled flavor of Linux. Been at the CLI since 1981, been compiling Linux since 1995.

Personally I would rather compile code myself. For a number of reasons.

1. If you have reviewed the code you are compiling, you know exactly what the binary will contain.
2. Trusting binaries that has been compiled by someone else is problematic.
   a. They could have added a patch that provides them with a backdoor access or phones home
   with data.
3. When you compile code, you can compile specifically for your processor/architecture flags and or
   flags used with other software that it interacts with.
4. You can produce your own build script to build it exactly how you want to build it.
5. Compiling acmetool with GO is a trivial matter.
6. Compiling acmetool is much faster & easier than writing your own tool to deal with getting certs.
7. Nothing is stopping anyone from forking many of the letsencrypt tools for getting certs.
8. Nothing is stopping anyone from writing their own letsencrypt tool for getting certs.
9. acmetool has been working just fine in production with no issues, nothing needs to be done.
10. Dev's are infamous for ignoring how other people think things should be done. See # 8

I know most of you use binary OS's. Therefore you are more dependent upon your package manager which is focused on binary installations. Yet you still have the choice to self compile. Most binary OS's are not setup very good for compiling, or what I should clarify, is package managing for self compiled code.

With Gentoo besides having the normal package manager Portage. That handles compiling flags and all the code/packages that there are existing ebuilds for. There is also an Overlay/Layman system that allows for producing your own and or community produced ebuilds for packages outside of the normal package repository. Great for testing purposes, if you want something outside what is normally provided.

If you are running a binary flavor of Linux, if your really want acmetool available via your package manager as a binary install. Every Linux flavor has a method for adding packages that are not already available. I suggest you look into how your Linux flavor allows for adding new packages to the repository. Then become it's package manager.

Most available packages in all Linux flavors are not maintained by the code developer. Some dev's do maintain binary installs for various Linux flavors, but most do not. The complexity of knowing how every single Linux flavor is structured, is simply to tedious & time consuming, also many regularly change. Most dev's leave it to the various Linux flavor package managers to produce binary installs for their flavor. Package manager's are intimate users of their Linux flavor, they are better positioned for competently building binary installs for their specific flavor.

As for Apple products they have their own tools for compiling code. But you can also run Gentoo Portage and take advantage of Gentoo tools, think it might still be supported in one manner or another. Can also install Gentoo as your primary OS on apple hardware, and or dual boot.

Windblows, no help for the lot of you. Purchase a $20 or up ssd and install Linux. Then you can boot to either installed on each others respective drive. No worry of cross contamination or loss of data during install. If you want a binary Linux I suggest Alpine, which was originally build from Gentoo, but is now independent. For the best for development, Gentoo. Both Gentoo & Alpine are systemd free, they both use Openrc, or you can use Runit or almost any other system init. There are many reasons why you do not want to run systemd, but this is not the place for that discussion.

With Gentoo you will learn a lot about Linux & have the most flexibility, also have access to documentation & forums to self educate. If you really want to learn Linux like those of us back in the cave days. LFS, Linux From Scratch is only instructions, no package manager, every piece of code must be hand compiled, with self set compilation flags, and self handled dependencies and their respective flags. Gentoo with it's Portage package manager makes flag handling & dependency handling easy. Gentoo is essentially LFS on steroids.

Rather than expecting something to be built for you. You are much better off taking the time to learn how to be self sufficient while increasing your knowledge & experience base. Being dependent upon a binary OS is severely limited. Open your world up to the other 99% & expand out to the rest of the universe. There is much to be said about Self Reliance.

[Amunak]

"Abandon" is a bit of a stretch imo -- the project maintainer has already added the required support for ACMEv2 in order to keep the tool viable.

The author hasn't touched the project or replied for at least half a year. Considering how many people already tested v2 and said it's more or less fine, the least they could do would be marking the release as stable and providing binaries with the release (and perhaps closing this issue). It's literally like 20 clicks here on Github if they just download one of the binaries that others already compiled.

"Migration" to ACMEv2 is entirely dependent on the user's particular setup and has little to do with acmetool itself. I have not created an account anywhere or used DNS hooks and everything is working fine.

When you use the ACME API AcmeTool creates an account for you with LetsEncrypt. This is transparent for the most part, but it has some consequences. When you delete your v1 account folder you lose that account and create a new one. It's not a big deal (I hope) but it doesn't feel like the "correct" way to do things.

Not being able to just tell AcmeTool to use the new API from now on is just stupid - there should be a clear and easy migration path.

A GitHub release for 0.2.1 has existed since October. The presence of a tagged release should satisfy package maintainers/build systems, and allow distribution packages to update.

Right, the minimum I'm asking for is promoting that tag into a full release.

Binaries on GitHub would be nice, but users should really be getting their binaries from their distribution. It is not the project maintainer's responsibility to compile software for you.

I mean, sure. It's "only" a "nice to have". But especially when the compiled thing is a single binary file it's not too hard to make a simple release with binaries.

---

Alternatively the author should just say fuck it, I don't want to work on this anymore, please someone fork it and work on it. That's a commendable approach, and I would totally understand it. It's not easy to maintain public projects for free. But silence for months is really, really bad.

[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/

[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

[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!

[sjamaan]

It's June now, and still no official release. I find this really frustrating; many people reporting that the application obviously is working, yet @hlandau is MIA.

One of the reason I'm using acmetool and not one of a gazillion other ACME clients is that binaries are available for many platforms. Even if a release was made now it would take upstream package maintainers a while before updating it.

[sjamaan]

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

[Mrten]

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

[snabb]

@sjamaan If you extract the acmetool binary from that Ubuntu package, you can use it as it is on CentOS and Debian. It is the nature of binaries produced by Go compiler that they don't really care about the Linux distribution in use. They work on any distribution as long as the processor architecture is the same and there is some libc and Linux system calls available.

[xbeaudouin]

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

[samm-git]

@Amunak just use deb built for testing on any other debian. It works

[Amunak]

Debian has packages, but they're in testing. You can simply download the .deb from the website and install it with dpkg -i.

Though I still find it kind of unacceptable to just abandon a project like this. My migration to v2 personally wasn't really great; the fact that you have to create a new account is less than ideal, and the DNS-01 verification hook I had to write for my provider is working less reliably than it did in v1.

[KeepBotting]

"Abandon" is a bit of a stretch imo -- the project maintainer has already added the required support for ACMEv2 in order to keep the tool viable.

"Migration" to ACMEv2 is entirely dependent on the user's particular setup and has little to do with acmetool itself. I have not created an account anywhere or used DNS hooks and everything is working fine.

A GitHub release for 0.2.1 has existed since October. The presence of a tagged release should satisfy package maintainers/build systems, and allow distribution packages to update.

Binaries on GitHub would be nice, but users should really be getting their binaries from their distribution. It is not the project maintainer's responsibility to compile software for you.

[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$ 

[defanator]

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

[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.

[pipiche38]

seems same as hlandau/acme.t#1

[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 #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.

[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.

[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

[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.

[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.

[jwkohnen]

If you don't want to compile yourself, but just want to download a binary from a trusted source, you can unpack the acmetool binary from debian testing directly:

joh@xanos:/tmp$ mkdir /tmp/acmetool
joh@xanos:/tmp$ cd /tmp/acmetool
joh@xanos:/tmp/acmetool$ wget https://ftp.debian.org/debian/pool/main/a/acmetool/acmetool_0.2.1-2_amd64.deb
joh@xanos:/tmp/acmetool$ ar x acmetool_0.2.1-2_amd64.deb
joh@xanos:/tmp/acmetool$ tar xaf data.tar.xz
joh@xanos:/tmp/acmetool$ file ./usr/bin/acmetool
./usr/bin/acmetool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a44542c06f02b077f39bd2b912dd8186f5356fc5, for GNU/Linux 3.2.0, stripped
joh@xanos:/tmp/acmetool$ ldd ./usr/bin/acmetool
	linux-vdso.so.1 (0x00007ffe0b07f000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f37e6e36000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37e6c19000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37e686d000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f37e6668000)
	/lib64/ld-linux-x86-64.so.2 (0x000055fe675d4000)
joh@xanos:/tmp/acmetool$ ./usr/bin/acmetool --version
go version go1.13.8 linux/amd64 gc cgo=true
acmetool Debian version 0.2.1-2

Go binaries are semi-statically built. They should work on any Linux system that uses glibc.

If you copy that file to /usr/bin/ on Debian remember to use dpkg-divert as in my comment above to protect your copy from being overwritten by the package manager.

Edit: changed URL to https. Note you'll get a certificate error that the hostname is www.debian.org instead of ftp.debian.org.

[dol]

@sjamaan Don't blame @hlandau for not releasing a binary version. There are already built versions out there. E.g https://launchpad.net/ubuntu/+source/acmetool/0.2.1-1/+build/18755756/+files/acmetool_0.2.1-1_amd64.deb taken from https://launchpad.net/ubuntu/+source/acmetool/0.2.1-1/+build/18755756
Just download it and extract the acmetool binary.

[oleg-fiksel]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

[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!

[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/

[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]

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 #322 (comment) @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 hlandau/acme.t#1 mentioned at #322 (comment) 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

[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.

[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 ?

[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 :(

[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 #322 (comment):

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 #322 (comment) 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.

[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 #322 (comment), 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

[MikeGodin]

Has there been any progress on resolving the issue that "github.com/godbus/dbus/v5" does not exist?

[Mrten]

other then upgrading go, no.

[SinOJosWeb]

Since my last post Feb 1 2020 acme v2 has been working flawlessly. All renews have completed, no interaction has been necessary.

[Amunak]

So ... the only thing really needed is for @hlandau to make an official release and (hopefully) have maintainers update their packages?

[samm-git]

@Amunak in fact nothing prevents maintainers to use published release now (this is exactly what i did as a FreeBSD maintainer)

[mnalis]

@Amunak Debian also built new packages upon receiving bug report; so you probably just need to contact your distribution package managers and indicate that they should upgrade the packages...

[Amunak]

@mnalis I do actually have debian on the server where I need v2, but it's only in Bullseye/testing as of now. Do you know if v2 will be backported to Buster, or do I have to experiment with backports/testing?

[KeepBotting]

Thanks, 0.2.1 works nicely for ACMEv2 when running acmetool, no further action needed

[sjamaan]

I need CentOS (and also plain Debian) packages, not Ubuntu ones. But making it an official release instead of a beta version would definitely signal to package maintainers that it's stable and can be put in a package.

[tomwaldnz]

I built acmetool on Amazon Linux a couple of days ago. Not sure why but the version isn't showing - any tips? If anyone wants this version I can make it available to download for a couple of days.

 ./acmetool --version
go version go1.13.4 linux/amd64 gc cgo=true
build unknown

[jwkohnen]

Having version information of the main module in the binary is a hard problem in Go at the moment: golang/go#29228

The author of acmetool has "solved" that in a ... unique way: https://github.com/hlandau/acmetool/blob/master/Makefile#L42 ... but as I've mentioned above, rather stay away from running make. It may ruin you day.

[tomwaldnz]

Having version information of the main module in the binary is a hard problem in Go at the moment: golang/go#29228

The author of acmetool has "solved" that in a ... unique way: https://github.com/hlandau/acmetool/blob/master/Makefile#L42 ... but as I've mentioned above, rather stay away from running make. It may ruin you day.

Update - I worked it out from this thread.

make USE_BUILDINFO=1

Unfortunately version information isn't included. Here's version info from v0.0.67

git github.com/hlandau/acme 221ea15246f0bbcf254b350bee272d43a1820285 v0.0.67

Here's what it is when we checkout from master

git github.com/hlandau/acmetool 13ec97e4f1cd8bc1b17a70443c46f6075c9e9fac heads/master

I did try checking out from a tag and doing a build but that didn't help. Anyone know how to get the acmetool version into the "acmetool --version" output?

git clone https://github.com/hlandau/acmetool.git --branch v0.2.1

[CL-Jeremy]

It's literally like 20 clicks here on Github if they just download one of the binaries that others already compiled.

From the author:

[...] You will need to build this yourself as release automation is being renovated.

So that's probably the bigger issue here. No pull requests can be merged unless CI is fixed. No binaries can be built, either.

I've been working on a allowing a head build using Homebrew for macOS. It's been building just fine, even on Linux (with the insertion of a single line: depends_on "libcap after line 19). The pull request has just been submitted: Homebrew/homebrew-core#55762. It will be also be merged to Linuxbrew once it gets approved on both sides. For now please download the formula file and add that line, then it could be built as per need.

I also built two bottles (binary packages), one for OS X 10.10 and one for macOS 10.15. Both could be used interchangeably on either of them as well as all versions in between. Currently the installation of head bottles is buggy: after running brew install --force-bottle <file_path>, the following warning will show up:

Warning: Bottle installation failed: building from source.

Press Ctrl+C to terminate the process here and run the following:

brew link acmetool && brew postinstall acmetool

And acmetool is ready for use.

Downloads:
acmetool--HEAD-13ec97e.catalina.bottle.tar.gz (Go 1.14.3)
acmetool--HEAD-13ec97e.yosemite.bottle.tar.gz (Go 1.12.17)

There is also an option to enable --devel build for beta versions, though it's rarely used. Bottles can then be maintained using version tags at a regular basis. I'll see what I can do if anybody happens to be interested.

Note that Homebrew packages need to be installed to the prefix it is built for, so these binaries require the default Homebrew prefix being at /usr/local, otherwise they will need to be built from source. The benefit with Homebrew/Linuxbrew: no root is needed as long as the infrastructure is properly configured.

[tomwaldnz]

I have built acmetool 0.2.1 on Amazon Linux with Go 1.13.4. I think it should work on any Linux machine, but I don't know for sure and I'm offering no support.

It will be available on (link removed) for a few days, after which I'll delete it and won't upload it again. If it gets too much traffic I'll take it down.

[tomwaldnz]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

404 page not found - perhaps you could confirm / edit your post to update the link?

[oleg-fiksel]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

404 page not found - perhaps you could confirm / edit your post to update the link?

Try again please. I forgot to make repository public. 😉

[CL-Jeremy]

Homebrew/Linuxbrew tap is ready: https://github.com/CL-Jeremy/homebrew-acmetool-v2
Enjoy!

[Fyne5]

Tested on Rocky Linux 8.9 and OK

yum install -y git make tar unzip curl wget

wget https://go.dev/dl/go1.21.5.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.21.5.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

git clone https://github.com/hlandau/acmetool.git
cd acmetool/
go env -w GO111MODULE=auto
make
make install

which acmetool

acmetool --version