TL;DR server admin needs to fix their side.
On 2020/12/21 14:41, Greg Steuck wrote:
> Unlike firefox, chromium, and openssl s_client, these command line tools
> fail to connect (openbsd-amd64-current):
>
> % curl --verbose https://oleg.fi/gentle-introduction-2020.11.tar.gz
> * Trying 91.232.156.79:443...
> * Connected to oleg.fi (91.232.156.79) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/cert.pem
> * CApath: none
> * (304) (OUT), TLS handshake, Client hello (1):
> * (304) (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
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
>
> % wget https://oleg.fi/gentle-introduction-2020.11.tar.gz
> --2020-12-21 14:31:08-- https://oleg.fi/gentle-introduction-2020.11.tar.gz
> Resolving oleg.fi (oleg.fi)... 91.232.156.79, 91.232.156.80
> Connecting to oleg.fi (oleg.fi)|91.232.156.79|:443... connected.
> ERROR: cannot verify oleg.fi's certificate, issued by ‘CN=R3,O=Let's
> Encrypt,C=US’:
> Unable to locally verify the issuer's authority.
> To connect to oleg.fi insecurely, use `--no-check-certificate'.
> % openssl s_client -connect oleg.fi:443
You aren't asking s_client to verify certificates. You also aren't asking
it to use SNI so it is returning only the default certificate.
> ---
> Certificate chain
> 0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.kapsi.fi
> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Domain Validation Secure Server CA
> 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Domain Validation Secure Server CA
> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Certification Authority
> ---
This one does have a valid chain ... but feeding the certificate into
openssl x509 -text -noout it only covers these:
DNS:*.kapsi.fi, DNS:kapsi.fi
Fixing that...
$ openssl s_client -CAfile /etc/ssl/cert.pem -connect oleg.fi:443 -servername
oleg.fi
CONNECTED(00000003)
depth=0 CN = oleg.fi
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = oleg.fi
verify error:num=20:unable to get local issuer certificate
verify return:1
write W BLOCK
---
Certificate chain
0 s:/CN=oleg.fi
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
>From this it is obvious that they are sending the wrong intermediate.
This will be happening in various places as some server admins just
used a static intermediate cert rather than correctly using the correct
one specified in the ACME response - letsencrypt recently changed to
issuing from a different intermediate certificate so the server admin
needs to catch up.
Firefox and Chromium still connect because they fallback to fetching
the intermediate from the URL specified in the "AIA" extension (again
can be seen by feeding the cert into 'openssl x509 -text');
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
CA Issuers - URI:http://r3.i.lencr.org/
I suppose libtls could possibly do something about this (i.e. to lookup
from the AIA CA Issuers URI) but it feels like a bit of a layer violation.
Other than that I don't think libressl can really workaround this
server misconfiguration.
It will be affecting other software too e.g. curl/wget built using
openssl fails too.
(Note this is not related to the forthcoming hack for chain compatibility
with old android versions - mentioning it because the article about it
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
is currently doing the rounds).
