Re: Consistent certificate validation

On Wed, 4 Dec 2019, François via curl-users wrote:

> curl certificate validation seems to depend on the SSL library used to build
> curl.

This is true. To some extent and for some things we can't even affect that and
then we just have to accept the differences, but where we can we should strive
to unify the behaviors as much as possible.

> In some cases like when linking with openssl,you need to provide the root
> certificate to be able to connect with curl --capath or curl --cacert. In
> case you are using the --capath option and curl is built with openssl, you
> must use c_rehash to create the needed symlinks.

That's due to how OpenSSL works. We can't escape that.

> However if curl is built like this without openssl like in this example:
...
> curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10
...
> there is no need to create the symlinks with c_rehash

--capath doesn't work with GnuTLS so you use --cacert to specify a PEM file,
and that works basically the same way with OpenSSL. Right?

> also you don't need to have the root certificate within the capath folder,
> and you can just provide the server certificate to cacert. curl will not
> complain about any "self signed certificate in certificate chain" because it
> did not know about the root CA.

This depends on what exact OpenSSL version you use, but yes you're correct.
curl with OpenSSL has been insisting that you provide a "full cert chain" when
you verify a server certificate.

We actually changed this just the other day when we made curl tell OpenSSL to
also accept "partial cert chains". See this PR:
https://github.com/curl/curl/pull/4655

> This is bothering because I don't want to authorize every single certificate
> signed by an authority, but just a single one,

I don't think it is too unreasonable to provide a full cert chain.

> which subject is matching the server I'm targeting. It also means that a
> script calling curl --cacert might break following an update of curl,

If that upgrade switches TLS backend, yes. Unfortunate, but true. If you use
the --capath it could break even worse. And if you'd use a specific TLS
version that suddenly becomes unsupported after the upgrade it would also
break. And if you... [imagine several other things that can break]

So yes, upgrades can break curl. Fortunately it isn't that common as we and
most distros and operating systems etc try to keep that to a minimum.

> so in the end the most portable way to use curl remains to use the
> --insecure option.

I find that a rather odd argument, but ok.

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-12-04