Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
nss: load libnssckbi.so if no other trust is specified #1414
Clarification Nit: You said "supports extended validation". Note that the term "extended validation" has a special meaning (https://en.wikipedia.org/wiki/Extended_Validation_Certificate ), and p11-kit doesn't implement that. This is just to make sure that nobody reading this ticket draws incorrect conclusions. I think your intention was to simply say that it provides "additional", or "more advanced" validation features.
Also note that NSS and p11-kit are separate projects. Your patch directly refers to the p11-kit-trust.so module.
I don't know if this works for everyone who uses curl with NSS. There might potentially be environments that don't make use of p11-kit-trust as a system-wide trust store.
Traditionally, the trust store library that is used by NSS is used libnssckbi.so, which is a library that is shipped as part of the NSS distribution. It contains both positive trust and negative distrust information.
p11-kit-trust.so is a fully compatible drop-in replacement for libnssckbi.so
On Fedora Linux specifically, we use the "update-alternatives" mechanism, to provide p11-kit-trust.so as a higher prioritized alternative to libnssckbi.so.
If you want this patch to work, if p11-kit-trust.so isn't installed, but only NSS is installed, then it might make sense to change your patch to load the library named "libnssckbi.so". On Fedora Linux, this should then automatically load the "p11-kit-trust.so" instead.
I should have better explained the idea behind. On systems where p11-kit is configured as a reliable source of trust, one can build curl with
I guess that @kaie could better explain how it works internally...
No, it's different from CURLOPT_CRLFILE.
The CA trust that Mozilla provides isn't limited to positive trust. It also covers negative trust, when a CA needs to be distrusted.
There are scenarios when removing a CA isn't sufficient/possible. An example is when someone has been given an intermediate CA, and only that intermediate CA needs to be distrusted. DigiNotar was such an example. Another are mis-issued end entity certificates for high value domains.
In practice, the dynamic revocation mechanisms don't work well, because CRL/OCSP checkins is optional, and failure to dynamically check will be ignored (otherwise you'd be locked out from captive portals).
Thus, when there's a good reason to block some CAs or specific certificates, Mozilla may add distrust information to the Mozilla CA bundle (in certdata.txt).
As of today, curl only loads the positive trust. The suggestion is to also load the distrust.
Although there's a file format available with distrust information in a file format that openssl loads, it seems that often that file isn't used. And nss-pem doesn't support this file format that contains distrust information (Files with the BEGIN TRUSTED CERTIFICATE header is the format that may contain both positive and negative trust.)That means, this approach doesn't seem ideal for curl when using NSS.
The native way for NSS to load both positive and negative trust, which is also the way that Firefox loads it, is by loading the libnssckbi.so module provided by NSS itself. (Or alternative by loading p11-kit-trust.so which is a more advanced dynamic mechanism to configure additional trust/distrust on top of the static lists.)
@kdudka how about this: