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