acme-client challenges

Hey, misclings,

I'm standing up a new domain on a server that's been deployed for a
while. Big thanks to Gilles Chehade for his guide (
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
), as well as for smtpd. As part of this, I'm finally trying to adopt
TLS everywhere. So I have everything that I need running using
self-signed certs (it's a vanity domain, so all the users can be relied
upon to accept self-signed certs), but that's increasingly less
acceptable.

Short form: with httpd working, contents of /var/www/acme reachable
(but not the empty dir) (as-installed perms on everything in /var/www),
stock configuration (and reduced forms of it to simplify), A records
pointing to simmonpatch.com and tserig.simmonpatch.com (the main and
one alternative used in minimal test), default/simplified configuration
of /etc/acme-client.conf and /etc/httpd.conf, using the let's encrypt
staging server, I get this:

$ doas acme-client -vvv 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.api.letsencrypt.org/directory:
directories
acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
comm
acme-client: bad exit: netproc(39958): 1

This is a later run; in earlier runs I removed keys after every
failure, until I realized that keys (and their names) are cheap. But
this is the same error seen before, multiple times. The extra v (which
has no effect) was there to see if maybe that would help. I can't find
any logs, and there don't seem to be any other switches/knobs to turn
up verbosity more. As it is, it's rather cryptic. 'directories' may be
an error, or just informational (like the two key loading lines, which
are not errors). 'bad comm' is bad error messaging (not from
acme-client, I think, but from the staging server, which is reporting
what it got).

I'm hoping someone is going to point out something that will make me
feel stupid, but that I can't see until it's pointed out.

Minimal httpd.conf and acme-client.conf:

server "simmonpatch.com" {
listen on * port 80
alias "www.simmonpatch.com"
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI"
}
}

(tested with an index.html in /var/www/acme: it's reachable with only
this, though 403 for /.well-known/acme-challenge/, which is probably
the point, so I made sure it was empty when invoking acme-client)

authority letsencrypt-staging {
api url "https://acme-staging.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}

domain simmonpatch.com {
alternative names { tserig.simmonpatch.com,
mail.simmonpatch.com, www.simmonpatch.com }
domain key "/etc/ssl/private/leo-simmonpatch.com.key"
domain certificate "/etc/ssl/leo-simmonpatch.com.crt"
domain full chain certificate
"/etc/ssl/leo-simmonpatch.com.fullchain.pem"
sign with letsencrypt-staging
}

(everything else got removed to test; yay /etc/examples!)

No AAAA records (not available from hosting provider), no DNSSEC (I
could do that, but it's said to be not required and to sometimes cause
problems). httpd works with the tls bloc installed pointing at my
self-signed cert. I got a different error once when the request used
the same key+cert name as self-signed.

Also (double-checking logs): there is no attempted connection from
anyone except me (my ip address) trying the acme-challenge url.
Presumably, then, let's encrypt fails before that?

Thanks for reading this far, at least. :-)

Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
It's odd that people think of programming as precise and methodical.
*Computers* are precise and methodical.
Hacking is something you do with a gleeful laugh.
-- Paul Graham, "The Word 'Hacker'"