On Sun, 05 Apr 2020 at 01:22:46 +0200, Jonas Smedegaard wrote: >> Ah, yes: The cause is that the system lack the hashes in /etc/ssl/certs. >> >> Sorry for bothering you with a bug outside of lacme - sharing these >> details only in case it might inspire you to provide clues when lacme >> runs into weird scenarios like that. > > In case you are curious, the cause is (most likely) bugs#923479 - my > server is an armhf box bootstrapped with QEMU. I _did_ put a workaround > in place for that exact bug, but evidently that failed.
I see, thanks for the follow-up! lacme *does* hostname verification by
default (ouf) but this is done internally by OpenSSL with
IO::Socket::SSL::default_ca() as default CA stores.
https://metacpan.org/pod/IO::Socket::SSL#IO::Socket::SSL::default_ca([-path|dir|-SSL_ca_file-=-...,-SSL_ca_path-=%3E-...-])%3E
On your system IO::Socket::SSL::default_ca() appears to have found a
suitable default. But with bogus /etc/ssl/certs hashes verify(1ssl)
seems equivalent to -no-CApath, and I'm indeed able to reproduce the
“error 2 at 1 depth lookup” error if I disable /etc/ssl/certs hashes:
$ curl -s
https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db
\
| openssl verify -CAfile /usr/share/lacme/lets-encrypt-x3-cross-signed.pem
-no-CApath -purpose sslserver -x509_strict
C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
error 2 at 1 depth lookup: unable to get issuer certificate
error stdin: verification failed
Let's close this, no? :-)
--
Guilhem.
signature.asc
Description: PGP signature
