Quoting Jonas Smedegaard (2020-04-05 01:13:45) > Quoting Jonas Smedegaard (2020-04-05 01:00:04) > > Quoting Guilhem Moulin (2020-04-04 20:53:16) > > > On Sat, 04 Apr 2020 at 20:18:28 +0200, Jonas Smedegaard wrote: > > > > C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > > > > error 2 at 1 depth lookup: unable to get issuer certificate > > > > [live] Error: Received invalid X.509 certificate from ACME server! > > > > > > This indicates that the received X.509 certificate isn't signed by the > > > CA specified as ‘CAfile’. More precisely, that > > > > > > openssl verify -CAfile $CAfile -purpose sslserver -x509_strict > > > </path/to/cert > > > > > > has a non-0 exit status. The default value for ‘CAfile’ is the lacme- > > > provided cross signed chain > > > /usr/share/lacme/lets-encrypt-x3-cross-signed.pem , > > > did you perhaps set it to something else? I'm not familiar with > > > verify(1ssl) error messages but it suggests that the the CA file doesn't > > > contain the full chain. > > > > > > Works for me with the default ‘CAfile’ value, at least: > > > > > > $ curl -s > > > https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db > > > \ > > > | openssl verify -CAfile > > > /usr/share/lacme/lets-encrypt-x3-cross-signed.pem -purpose sslserver > > > -x509_strict > > > stdin: OK > > > > > > Does this command work on your system? > > > > Nope: > > > > debian@everton:~$ curl -s > > https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db > > | openssl verify -CAfile /usr/share/lacme/lets-encrypt-x3-cross-signed.pem > > -purpose sslserver -x509_strict > > unable to load certificate > > 3070115856:error:0909006C:PEM routines:get_name:no start > > line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE > > debian@everton:~$ echo $? > > 2 > > > > Weirdly the cause seems to be that curl doesn't get the cert at all: > > > > debian@everton:~$ curl -s > > https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db > > debian@everton:~$ echo $? > > 60 > > > > On another host I have no problem fetching the cert. > > > > So seems like an issue unrelated to lacme :-/ > > Seems to be a problem with CA certificates generally: > > debian@everton:~$ curl -s > https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db > --verbose > * Expire in 0 ms for 6 (transfer 0x5f25a8) > [...] > * Expire in 50 ms for 1 (transfer 0x5f25a8) > * Trying 172.65.32.248... > * TCP_NODELAY set > * Expire in 200 ms for 4 (transfer 0x5f25a8) > * Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * successfully set certificate verify locations: > * CAfile: none > CApath: /etc/ssl/certs > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (OUT), TLS alert, unknown CA (560): > * SSL certificate problem: unable to get local issuer certificate > * Closing connection 0 > > 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
