Re: Does cURL accept a CA that is not self signed?
Date: Thu, 28 Nov 2019 21:02:49 -0500
On Thu, Nov 28, 2019 at 4:58 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 28 Nov 2019, Jeffrey Walton via curl-library wrote:
> > I'm having trouble connecting to a server that uses Let's Encrypt.
> With a huuuge portion of the web now using Let's Encrypt certs, I would've
> expected more people to report problems if that would be the case.
Are folks using the Let's Encrypt X3 ca certificate, or the CA Zoo
with 137 ca's?
If it is the CA Zoo, then folks have exponentially increased their
attack surface. I still remember Diginotar [0,1], and more recently
companies like Symantec issuing certificates for domains they had no
administrative or relationship with or operational control over .
> I presume you use a recent curl with OpenSSL?
cURL and OpenSSL are provided by Fedora 31.
$ openssl version
OpenSSL 1.1.1d FIPS 10 Sep 2019
$ curl --version
curl 7.66.0 (x86_64-redhat-linux-gnu) libcurl/7.66.0 OpenSSL/1.1.1d-fips ...
> I don't quite understand your remark on needing X509_V_FLAG_PARTIAL_CHAIN. Are
> you not using a full "chain" ?
No. I'm only using the Let's Encrypt X3 ca certificate. I only use the
CA needed for the end entity certificate at hand.
I don't want the CA Zoo. I [almost] never use it.
I attached the reproducer (for me).
 Pastebin with the bad cert from Diginotar: https://pastebin.com/ff7Yg663
Sadly, the post from the kid from Iran who blew the lid off Diginotar
is no longer available at . The Google Webmaster deleted his post
(what a fucking idiot, given the historical significance). I have a
copy on it in my inbox. I emailed the text of the post and URL to
myself before the geniuses at Google deleted it.
Here's some output using CURLOPT_VERBOSE.
* Trying 172.16.2.1:443...
* TCP_NODELAY set
* Connected to example.com (172.16.2.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: ./letsencrypt-ca.pem
* SSL certificate problem: unable to get issuer certificate
* Closing connection 0
Error 60, SSL peer certificate or SSH remote key was not OK.
Here's an ldd on the test executable.
$ ldd test.exe
libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f79aee55000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f79aed3b000)
librt.so.1 => /lib64/librt.so.1 (0x00007f79aed30000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f79aed29000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f79aed07000)
libc.so.6 => /lib64/libc.so.6 (0x00007f79aeb3e000)
libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f79aeb13000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f79aeaf1000)
libssh.so.4 => /lib64/libssh.so.4 (0x00007f79aea81000)
libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f79aea6e000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f79ae9d8000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f79ae6f8000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f79ae6a4000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f79ae5b3000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f79ae59a000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f79ae593000)
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f79ae542000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f79ae531000)
libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f79ae520000)
libz.so.1 => /lib64/libz.so.1 (0x00007f79ae506000)
libm.so.6 => /lib64/libm.so.6 (0x00007f79ae3c0000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f79ae23c000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f79ae22a000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f79ae221000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f79ae208000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f79ae1e8000)
libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f79ae1c5000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f79ae198000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f79ae15b000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f79ae0cd000)
- text/x-c-code attachment: test.c