Bug#955765: Error: Received invalid X.509 certificate from ACME server!
On Sun, 05 Apr 2020 at 01:47:39 +0200, Jonas Smedegaard wrote: > lacme succesfully issed a cert! \o/ -- Guilhem. signature.asc Description: PGP signature
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
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
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
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 > > > > > > > > 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
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
On Sun, 05 Apr 2020 at 01:00:04 +0200, Jonas Smedegaard wrote: > 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 :-/ Not sure if it's unrelated, curl(1)'s exit status 60 is “Peer certificate cannot be authenticated with known CA certificates.” Is ca-certificates installed on that machine? It occurs to me that a dependency might be missing here. Oddly enough lacme is able to talk to the server, even though its ‘SSL_verify’ option defaults to ‘Yes’, which AFAICT causes IO::Socket::SSL to use the peer verification logic from openssl. -- Guilhem. signature.asc Description: PGP signature
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
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 > > > > > 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. - 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
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
Quoting Guilhem Moulin (2020-04-04 20:53:16) > Control: tag -1 moreinfo > > Hi Jonas, > > 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 > > 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 :-/ > (Adding --debug will indicate the exact `openssl verify -CAfile …` > that fails.) Here's the output with --debug (in case it is still interesting): Using configuration file: /etc/lacme/lacme.conf Reading /etc/lacme/lacme-certs.conf Reading /etc/lacme/lacme-certs.conf.d/live.conf Configuration option for live: CAfile = /usr/share/lacme/lets-encrypt-x3-cross-signed.pem certificate-chain = /etc/ssl/shared/live.pem certificate-key = /etc/ssl/private/live.key notify = /bin/systemctl reload apache2 subject = /CN=live.homebase.dk Certificate Request: Data: Version: 1 (0x0) Subject: CN = live.homebase.dk Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) Modulus: 00:ab:58:69:4a:3d:a4:aa:23:7f:28:62:70:86:fa: 29:c1:3d:c5:e1:46:07:a9:b6:70:ab:31:13:d5:ba: 79:f2:8e:cc:43:30:b3:9b:bc:36:fd:79:b0:25:07: 61:06:b7:8e:74:bd:15:44:45:47:46:23:b7:d2:b1: e8:ca:8f:c4:41:52:89:33:79:c7:6a:70:43:f0:28: 31:87:18:57:23:6b:88:e5:75:2c:9e:38:3a:d2:34: 4a:f8:b9:19:9a:b3:97:bf:94:5a:fd:61:4f:ae:d0: 58:2c:58:6a:b1:7d:74:2e:93:3d:eb:c5:04:78:04: 9d:ba:b0:c2:65:ea:24:0d:93:ae:09:ca:02:b9:80: cb:46:6d:f7:32:4a:48:76:6f:7d:2e:2f:5c:b0:42: d6:6e:f3:db:ad:5f:d7:14:5b:f3:f1:68:c4:b0:b1: d5:99:33:3a:df:24:64:76:94:37:93:60:48:25:16: f5:4b:1d:a9:40:c3:55:6c:f0:22:75:ef:80:ac:d2: e5:f0:1f:6d:de:ab:e1:f1:01:4f:3f:1a:99:1b:2b: 18:53:2f:d3:9c:ee:d5:99:38:49:69:b7:b2:39:10: c4:41:55:f1:13:09:b3:5e:a3:2f:14:23:12:ff:af: ad:de:82:63:71:0b:a4:9f:a3:1f:1f:40:a7:79:4c: 6e:06:fc:a5:03:0c:8d:ef:4c:25:f3:bd:ad:8e:1d: db:3c:4e:3b:41:48:f9:4a:2e:6e:68:03:68:e7:88: 43:2b:ba:35:4e:ad:79:13:1b:1f:96:c1:63:29:cd: 89:73:14:d1:f3:2d:11:b4:ad:c5:42:52:b3:33:27: 07:d6:3c:10:1d:e1:84:0d:57:45:6a:1c:da:25:a2: 48:71:84:41:5b:05:7b:0f:da:d9:2f:73:76:0d:82: e0:00:f4:94:87:fa:88:7c:b9:ef:d1:c2:96:52:1c: 9d:cd:1f:0f:d1:b5:ab:81:7e:47:1d:01:a5:95:e9: ea:85:0c:c8:9d:1c:57:95:58:e5:14:c3:7a:c2:15: 26:3d:27:bf:f2:ea:d7:85:53:6a:b5:9b:f1:02:69: 2d:3d:10:04:7e:46:b9:bb:78:6d:da:49:d1:b3:9e: 30:a3:a2:11:22:1e:cd:fe:ad:e9:85:e2:6c:93:cd: da:72:8d:ad:cf:91:18:42:c7:68:d5:f1:58:fa:66: f7:99:f0:1c:f9:9b:4a:1b:e4:dc:f9:4c:d5:8f:8c: 91:79:38:55:1c:e2:a6:83:5d:9e:f9:a9:b0:cf:41: d4:1e:dc:17:76:30:5d:e8:52:44:62:73:83:b6:33: 46:85:fa:4a:fe:4e:de:9b:19:a4:12:52:a8:a1:e0:
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
Control: tag -1 moreinfo Hi Jonas, 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 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? I've not been able to reproduce the “error 2 at 1 depth lookup” error, but for a completely different CA verify(1ssl) fails with: $ curl -s https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db \ | openssl verify -CAfile /usr/share/lacme/lets-encrypt-x1-cross-signed.pem -purpose sslserver -x509_strict CN = live.homebase.dk error 20 at 0 depth lookup: unable to get local issuer certificate error stdin: verification failed (Adding --debug will indicate the exact `openssl verify -CAfile …` that fails.) -- Guilhem. signature.asc Description: PGP signature
Bug#955765: Error: Received invalid X.509 certificate from ACME server!
Source: lacme Version: 0.6-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I cannot get lacme to issue a certificate :-( I run lacme-accountd from my laptop, and lacme on my server with an ssh-tunneled socket to lacme-accountd. Here's the output from lacme: Certificate URI: https://acme-v02.api.letsencrypt.org/acme/cert/036c9c4c3720c2241c7f32cb5920470555db 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! Apology ahead if I am missing something obvious and effectively abusing this as a support forum. I have run out of ideas to explore on my own. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6Iz3IACgkQLHwxRsGg ASF5fRAAnJhiQfGE9A62QGYB97smRftL8FaDrq4EjsJV2dv43GrGnEmDivCaY94i K19rMhkh8xNEKrhZxpnf9VT8KcijxXxfF7C0WBkcSdiizOKARU3JQtkvahcB/V1G L8AR74PGrBhIQDcq3+TToKW/UUWGwSdghsH2/C1gN066at9BB0u20Afc3ZSZobT2 236Llwt3XEO7nP5YufJ1pL/PKIbmWpShCj7hUm9WwJF3pEYv/BubEQk7nD90+AK5 +dhYOu5EJudpR6EHL0nwUY5VO/eKgwsZThWuz0FqZ1sFghvC1U/SLaOED+0eZjat 3XRMkpnFxoN1fcjRGa3CDYgeUiJ9JJwhSfmvBE4WlGCGrkltjzOaUwO+tl53UqL7 /13Jlh/FiV8j8yVu71GvbJ9baT6sINOGex2C7L/7Ga4k3oxtNj+cVK9HWosnD50W zTJ49/QDmiA1TMpH7/ovwP6VN9+KF1/xChZSMJrrxXQwFFjREF6v0R2+u+PKeHDF JJ919yMGiQeDMlXVg3P6DP/8neOmjIP+sVKpoK3WHF2chBxwm4PzWPbz+btd0f6r zx97EkpazfKYEUqLpKtZ+SCz5tRI2ajCGlOP8xpaQYWfjiG8x9KKBcJ93+H7CalO 7r/PgDGU0zBPuUJLF9UUX6tAXjxOH1nto9JwnI0O+fwezrxRXx4= =RWn1 -END PGP SIGNATURE-
