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'"
