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 <amyzing@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 (amyzing@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!
No comments:
Post a Comment