[SOLVED] openbsd acme-client "No registration exists matching provided key"
*BSDThis forum is for the discussion of all BSD variants.
FreeBSD, OpenBSD, NetBSD, etc.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
openbsd acme-client "No registration exists matching provided key"
I'm getting an error with acme-client on a recent snapshot of OpenBSD. The acme-client responds "No registration exists matching provided key" when I try to renew a certificate. There have been some changes to the acme-client since I set this up long ago and I may be missing some of them. I don't have a good overview of the certificate process so the mistake is not clear to me.
How recent a snapshot? Your configuration file appears to be out-of-date with changes to acme-client. In particular, I recall revising my configuration to remove agreement url. See acme-client.conf(5), and perhaps run acme-client with -n.
Edited to add: it wasn't that long ago - the commit to revise was in November. From the CVS log for acme-client.conf.5:
Code:
revision 1.11
date: 2017/11/27 01:58:52; author: florian; state: Exp; lines: +2 -8; commitid: u4hM2TeZ9dAhUyQs;
Deprecate agreement url config option and get the information from the
directory call. This way we don't need to update the acme-client.conf
file every time it changes. Still parse the option, ignore and warn about
it for a release. Sysmerge should be able to handle the removal.
"nice" deraadt@
OK benno
Last edited by jggimi; 12-15-2017 at 06:23 AM.
Reason: history
The snapshot is only from Dec 9, not quite the latest.
I see however, that the /etc/examples/acme-client.conf still has the agreement links. So, I tried building acme-client.conf(5) from scratch, ignoring the /etc/examples/ version. The .conf file I had was quite old and has been carried forward for ages. I'm not sure that the changes are well-documented. I do check the "Following -current" page in the FAQ periodically.
Anyway, clearing acme-client(5) and replacing it with this works:
Code:
authority letsencrypt {
api url "https://acme-v01.api.letsencrypt.org/directory"
account key "/etc/ssl/private/my-acme.key"
}
domain foo.example.com {
domain key "/etc/ssl/private/foo.example.com.key"
domain certificate "/etc/ssl/foo.example.com.crt"
domain full chain certificate "/etc/ssl/foo.example.com.fullchain.pem"
sign with letsencrypt
}
Also, somehow /etc/ssl/private/my-acme.key was empty, so erasing it was also necessary.
I now get:
Code:
# time acme-client -DAv foo.example.com
acme-client: /etc/ssl/private/foo.example.com.key: domain key exists (not creating)
acme-client: /etc/ssl/private/my-acme.key: account key exists (not creating)
acme-client: /etc/ssl/foo.example.com.crt: certificate valid: 89 days left
0m01.71s real 0m01.53s user 0m00.13s system
Was there anything I should have been tracking to know about the changes to acme-client.conf(5) in time?
The snapshot is only from Dec 9, not quite the latest.
I see however, that the /etc/examples/acme-client.conf still has the agreement links.
On my system, there is no example file. Nor is there one in the source tree. I am unsure where your example file came from, as there isn't even one in the CVS Attic. http://cvsweb.openbsd.org/cgi-bin/cv.../etc/examples/
Quote:
...I do check the "Following -current" page in the FAQ periodically...Was there anything I should have been tracking to know about the changes to acme-client.conf(5) in time?
I follow the same FAQ page. But I also track a number of mailing lists, including misc@ and bugs@. I recall reading about the agreement URL issue, but I can't recall where, and a quick search comes up empty.
Thanks. I'll have to focus better. It probably rolled past without standing out.
I do check the mails after doing an update to a new snapshot and sysmerge(8) itself produces a lot of repetitive chatter of late. It does not like the changes I have in many configuration files, most notably pf.conf(5) and sshd_config(5). I guess I'll have to figure out a new workflow to deal with the new sysmerge(8) while still doing frequent snapshots.
I agree but I am somewhat curious as to how it zeroed out. The update process for Let's Encrypt has been running fine as part of weekly.local with the same keys since the acme-client(1) hit production, albeit with one update to change around the options to match the new client.
You will have two weekly run history files: /var/log/weekly.out and /var/log/weekly.out.old -- older than that would depend on your backup/archive mechanisms, or whether you retain the Emailed logs.
Late on 2 Dec, long after weekly ran, I updated to the 1 Dec snapshot on that box.
Before that I had been running the 24 Nov snapshot for a while.
OpenBSD 6.2-current (GENERIC) #256: Fri Nov 24 09:32:04 MST 2017
OpenBSD 6.2-current (GENERIC) #258: Fri Dec 1 17:04:59 MST 2017
As far as the configuration files go for that box, I do regular backups of them, but those backups are made on-demand if/when I change the files to keep old versions from rotating out of reach too soon.
Based on that, it's possible the key was damaged by something in the December 1 snapshot. But recreating each environment to see if you can reproduce the problem and then capture the root cause would be a lot of work, and may not be fruitful.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.