Thanks for the response, Florian, On Tue, 31 Dec 2024 06:55:26 +0100, Florian Obser wrote: > On 2024-12-30 19:44 -05, Amelia A Lewis <amyz...@talsever.com> wrote: >> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad >> comm >> acme-client: bad exit: netproc(39958): 1 > > your acme-client.conf is about 5.5 years too old: > https://cvsweb.openbsd.org/src/etc/examples/acme-client.conf#rev1.2 > > The correct staging url is > https://acme-staging-v02.api.letsencrypt.org/directory
I worked that out, with updated results: $ doas acme-client -vv simmonpatch.com acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account key acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key acme-client: https://staging.api.letsencrypt.org/directory: directories acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172 acme-client: 172.65.46.172: tls_write: name `staging.api.letsencrypt.org' not present in server certificate acme-client: 172.65.46.172: tls_read: name `staging.api.letsencrypt.org' not present in server certificate acme-client: https://staging.api.letsencrypt.org/directory: bad comm acme-client: bad exit: netproc(18286): 1 I think that this is because I experimented with it in 2019 or so (which would have gotten the created copy that I modified further on taking it up again Sunday). My /etc/examples/acme-client.conf is, like yours, pointing at acme-v02.api and acme-staging-v02.api, and this looks like my major bit of stupidity, overlooking the difference between what I had and what was in examples. Here's an updated-just now minimized version, using the specified hostnames (and not the canonical hostnames, which in a moment of less fatigue occurs to me could be the reason it gave the response above last night, so a second bit of working-too-late fatigue). > If your acme-client is the same vintage you probably need to update, I > don't think it will be able to talk to a v2 api endpoint. I think I was stupid again, using the staging.api hostname. $ doas acme-client -nv simmonpatch.com doas (amyz...@tserig.simmonpatch.com) password: authority letsencrypt { api url "https://acme-v01.api.letsencrypt.org/directory"; account key "/etc/acme/letsencrypt-privkey.pem" rsa } authority letsencrypt-staging { api url "https://acme-staging-v02.api.letsencrypt.org/directory"; account key "/etc/acme/letsencrypt-staging-privkey.pem" rsa } domain simmonpatch.com { domain name "simmonpatch.com" alternative names { tserig.simmonpatch.com } domain key "/etc/ssl/private/leo-simmonpatch.com.key" rsa domain full chain certificate "/etc/ssl/leo-simmonpatch.com.fullchain.pem" sign with "letsencrypt-staging" } and this looks more promising, as loads of debugging scrolls past, but dammit! One more request for a look: is there anything sus in the above or in the below output? I'll have to look at it more carefully after coffee, but I wouldn't mind being given a cheat code. The original output is very long, so let me snip three lines from the bottom first, then the whole output in order. The whole thing has a bunch of lines wrapped (mua wraps them on send), but I figured better to be complete, and not to try sending an attachment. Okay, original very long output had three alt names, two of them 'service' style aliases for the A record which is the sole alt name above (both the domain A record and the machine name A record have been in DNS for five years or more at that IP; not so the CName-s, which were changed recently). Same three final lines (different numbers in 'netproc(nnnnnn)'), short form is the latest run of three (domain+3 alts, domain+2 alts, domain+1 alt above and full output below). -- last three -- acme-client: order.status 2 acme-client: unhandled status: 2 acme-client: bad exit: netproc(68704): 1 -- whole thing (third run, using-- $ doas acme-client -vv simmonpatch.com acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account key acme-client: https://acme-staging-v02.api.letsencrypt.org/directory: directories acme-client: acme-staging-v02.api.letsencrypt.org: DNS: 172.65.46.172 acme-client: transfer buffer: [{ "FIupg6fYm1w": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417";, "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change";, "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf";, "website": "https://letsencrypt.org/docs/staging-environment/"; }, "newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct";, "newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce";, "newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order";, "renewalInfo": "https://acme-staging-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo";, "revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"; }] (820 bytes) acme-client: transfer buffer: [{ "key": { "kty": "RSA", "n": "wSD4AguvgUpDYY5_H14dbVvAVLQMkzNamr8svtf35mKpIT0bNJzRtDPoFg2dq_FyDQVWKbqa5dzCKo50526q9YXNEMS8IpIFxapNByaLo4QByVfghziikPyZYPnrcWS40lXQsNARN7crO89eqneJOdThT0BglDqPowso1K9QWAnOXrieqRAqu_8laG3WtBBb0MIMKI_qeakWwVrno_WCk973O4JiMBheHxsY8ikSmd5P1qtU9wIio9hVWqjzSVgdtpIJL7IaXg0uD2nEaZRf8KMBGz0pnyuMpd1rpsQozKE0o3JAZ-22qXaCFf57kjn7RwiXAEgBv2ZaiUAehroN6al8FzqtXkQdBncmQh8XmqT6FkRoF0kbhRTZw4lhLc8h2GlzDL-ZPcocmYUUyUzLQXdadv4fDXwlZ3WDyC0L3ZFZowYJZBivtgBZyBGRWp2oPMMqbn3i9DNycuZfe51VIjnbdKpdxqj7yPc-ot6hsuCVByHPVr2YPfx4j4YSZAp_XC_wPoDmfFrI4w8Gy6tq1MkG6zFSkpE3MSX-_8hi-r8sj7KXmgpUIeLNft2pXTCAppxbn8XZAjwzpr0QKEQ7P19fp0T8dzhSCWzYh5DAxYdF0S4yWVaT2f7GHiuZmza9TexzDlbV1kbjEyTMzG5WwwNvGzZPs8P5m0M0IO9HiUE", "e": "AQAB" }, "createdAt": "2024-12-31T12:27:50Z", "status": "valid" }] (808 bytes) acme-client: transfer buffer: [{ "status": "ready", "expires": "2025-01-07T12:52:07Z", "identifiers": [ { "type": "dns", "value": "simmonpatch.com" }, { "type": "dns", "value": "tserig.simmonpatch.com" } ], "authorizations": [ "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944";, "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"; ], "finalize": "https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"; }] (518 bytes) acme-client: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374: certificate acme-client: transfer buffer: [{ "status": "processing", "expires": "2025-01-07T12:52:07Z", "identifiers": [ { "type": "dns", "value": "simmonpatch.com" }, { "type": "dns", "value": "tserig.simmonpatch.com" } ], "authorizations": [ "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944";, "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"; ], "finalize": "https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"; }] (523 bytes) acme-client: transfer buffer: [{ "status": "processing", "expires": "2025-01-07T12:52:07Z", "identifiers": [ { "type": "dns", "value": "simmonpatch.com" }, { "type": "dns", "value": "tserig.simmonpatch.com" } ], "authorizations": [ "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944";, "https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"; ], "finalize": "https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"; }] (523 bytes) acme-client: order.status 2 acme-client: unhandled status: 2 acme-client: bad exit: netproc(66411): 1 Thanks for the help, and if you've gotten to here, thanks for looking through the above (all three complete attempts are in scrollback, if it's more useful to see the sequence, but all three in end in order.status 2 / unhandled status: 2 / bad exit: netproc following "finalize"). I can send them if someone needs to see them to diagnose. Do I just need to wait until the expires timestamp (2025-01-07T12:52:07Z) or something, perhaps? Amy!
