On Friday, April 07, 2017 13:34:42 Kai Engert wrote: > On Fri, 2017-04-07 at 11:54 +0200, Kamil Dudka wrote: > > On Friday, April 07, 2017 11:01:35 Kai Engert wrote: > > > On Fri, 2017-04-07 at 10:38 +0200, Kamil Dudka wrote: > > > > Although we build libcurl against NSS now, it loads the same CA bundle > > > > as > > > > if we built it against OpenSSL: > > > > > > > > /etc/pki/tls/certs/ca-bundle.crt > > > > > > > > So I doubt it could actually take advantage of those extra flags. > > > > > > This file doesn't contain the distrust flags. > > > > > > The correct file would be /etc/pki/tls/certs/ca-bundle.trust.crt > > > > Yes, but it does not make sense to load such a file by nss-pem because it > > does > > not support those flags anyway. The correct fix for NSS-linked libcurl > > would probably be to just disable loading the CA roots from file by > > default. > Why do you mentioned a need to fix curl-nss? Because the NSS-linked libcurl in Fedora currently works in a way that it does not take advantage of the extended validation features implemented in NSS, as I understand it. > The regular approach for NSS applications is to load the NSS libnssckbi.so > (now the drop-in replacement p11-kit-trust.so), which provides all trust > and distrust information in a format that NSS can handle. > > How does curl-nss load the CA trust list? libcurl loads /etc/pki/tls/certs/ca-bundle.trust.crt using the nss-pem module. > If curl-nss doesn't load libnssckbi.so/p11-kit-trust.so but rather loads a > simple PEM file, then today's curl-nss doesn't use distrust information. Exactly. It sounds like there is still some room for improvement. Kamil > Kai _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
