LinuxQuestions.org - [SOLVED] openbsd acme-client "No registration exists matching provided key"

- *BSD (https://www.linuxquestions.org/questions/%2Absd-17/)

- - openbsd acme-client "No registration exists matching provided key" (https://www.linuxquestions.org/questions/%2Absd-17/openbsd-acme-client-no-registration-exists-matching-provided-key-4175619663/)

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.

What have I done incorrectly here?

Code:

# acme-client -DAvv foo.example.com 

acme-client: /etc/ssl/private/foo.example.com.key: domain key exists (not creating)

acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists (not creating)

acme-client: acme-client: /etc/ssl/foo.example.com.crt: certificate renewable: 20 days left

/etc/ssl/private/foo.example.com.key: loaded RSA domain key

acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key

acme-client: https://acme-v01.api.letsencrypt.org/directory: directories

acme-client: acme-v01.api.letsencrypt.org: DNS: 104.122.243.227

acme-client: transfer buffer: [{ "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change", "xxxxxxxxxxx": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/xxxxx", "meta": { "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf" }, "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg", "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert" }] (562 bytes)

acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth: foo.example.com

acme-client: acme-v01.api.letsencrypt.org: cached

acme-client: acme-v01.api.letsencrypt.org: cached

acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 403

acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "No registration exists matching provided key", "status": 403 }] (120 bytes)

acme-client: bad exit: netproc(70404): 1

The acme-client.conf file contains:

Code:

authority letsencrypt {

        agreement url "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"

        api url "https://acme-v01.api.letsencrypt.org/directory"

        account key "/etc/acme/letsencrypt-privkey.pem"

}



authority letsencrypt-staging {

        agreement url "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"

        api url "https://acme-staging.api.letsencrypt.org/directory"

        account key "/etc/acme/letsencrypt-staging-privkey.pem"

}



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

        challengedir "/var/www/acme"

}

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

Thanks.

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?

Quote:

Originally Posted by Turbocapitalist (Post 5793465)

Thanks.

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.

Ok. Thanks.

For what it's worth the amce-client.conf file that I have in the example folder had this this at the top:

# $OpenBSD: acme-client.conf,v 1.5 2017/11/15 12:22:45 florian Exp $

However, it's a production machine that's been online for a very long while so things can and do get stirred around.

Ah! That is not in /etc/examples -- that's in /etc. My apologies for the confusion.

You would have been informed of changes to the file in /etc via sysmerge(8).

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 will guess that the root cause of the problem was your missing key, and not this relatively minor configuration file change. :)

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.

The old weekly.local had:

Code:

/usr/sbin/acme-client -v \

      -C /var/www/acme/ \

      -c /etc/ssl/acme/ \

      -k /etc/ssl/acme/private/privkey.pem \

      -f /etc/acme/privkey.pem \

      foo.example.com

The new weekly.local has:

Code:

/usr/sbin/acme-client -v foo.example.com

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.

Thanks. The old one from 2 Dec shows the client running fine:

Code:

Running weekly.local:

acme-client: /etc/ssl/foo.example.com.crt: certificate valid: 33 days left

The new one from 9 Dec shows the error discussed above.

The most recent changes to acme-client were all committed on 27 November. Do you know which -current system you were running on Dec 2 vs. Dec 9?

Perhaps your backups will indicate when the file was damaged.

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.