From Fedora Project Wiki

Shared System Certificates

Summary

Make NSS, GnuTLS, OpenSSL and Java share a default source for retrieving system certificate anchors and black list information. This is an initial but useful step in the direction of a comprehensive solution.

Owner

Current status

Detailed Description

The goal is to have a systemwide trust store of static data, that is used by crypto toolkits as input for certificate trust decisions.

By default, the trust store will continue to contain the trust list as published by the Mozilla CA Certificate list (but use of others are possible), including positive and negative trust (blacklisted certificates). The system will allow updating of the core Mozilla CA list. The trust list can be adjusted, added to and overridden by administrators.

There will be two global directories that are scanned for input files, which will include the RPM-package-owned Mozilla trust bundle, and which may contain any number of additional files. One directory is used for default trust lists (/usr/share/pki/ca-trust-source), and another one for system specific trust (/etc/pki/ca-trust/source) which is interpreted with a higher priority.

In order to achieve this, the following implementation would be used. Much of the upstream implementation of this is p11-kit and can be shared with other distros.

This initial implementation is a step towards a later more comprehensive representation of locally stored trust policy information. The upstream p11-kit project has more information on the long term concept.

  • p11-kit will provide a PKCS#11 trust module which provides trust information based on a directory of certificates, some of which may have trust information attached.
    • The PEM trusted certificate file format is supported here, as are others.
  • p11-kit will provide a tool to extract information from the PKCS#11 trust module in the following formats:
    • Extract to a CA PEM bundle with TRUSTED CERTIFICATE information for OpenSSL.
    • Extract to a dirhash style directory for OpenSSL.
    • Extract to a CA bundle with plain certificates, for serverAuth, clientAuth, etc.
    • Extract to the Java cacerts file.
    • This tool uses the PKCS#11 module as its source of trust information, allowing future work to build off of this effort.
    • This tool is an interim bridge between OpenSSL, GnuTLS and Java until they are able to read PKCS#11 trust information directly.
  • NSS: Uses the above PKCS#11 trust module directly to pull in trust information.
    • The PKCS#11 trust module is a drop in replacement for libnssckbi.so.
    • We can use update-alternatives to manage this drop in replacement.
    • NSS using applications would not need to be changed to work with this module.
  • OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the PKCS#11 trust module.
    • These extracted certificates will be placed in a location so that they can be consumed by OpenSSL by default.
    • The aim is that neither OpenSSL nor OpenSSL applications will have to be changed for this to work.
    • In the long term future we hope that we can build a bridge so that OpenSSL can consume trust information directly from the PKCS#11 trust module.
  • GnuTLS: The p11-kit tool tool will extract a CA bundle to be used by GnuTLS from the PKCS#11 trust module.
    • This CA bundle would be placed in the location where most GnuTLS applications today are configured to use it.
    • It would pull out all the certificates that are trusted for serverAuth since GnuTLS does not yet provide a way to consume detailed usage directly.
    • Black listed certificates would obviously not be included in this bundle.
    • We are working with GnuTLS can consume trust information from the PKCS#11 trust module in the future.
  • Java: The p11-kit tool will extract a Java compatible cacerts file from the PKCS#11 trust module.
    • Again it is our aim that this changes later, once we can provide a bridge for java to load trust information from PKCS#11.

The recurring theme is that the PKCS#11 trust module is the source of trust policy information. Over time, (but not in this Fedora release) there will be:

  • Work done to both make the trust module have a comprehensive model of stored trust policy.
  • Steps taken to make it possible to use GnuTLS, OpenSSL and Java directly with that stored trust policy.

Obviously applications can continue to use their own CA list as appropriate, for example in servers such as httpd or postfix.

For more information:

Benefit to Fedora

The goal is to empower administrators to configure additional trusted CAs, or to override the trust settings of CAs, on a systemwide level, as required by local system environments or corporate deployments. Although this is theoretically possible today, it's extremely hard to get right.

Fedora will immediately gain a unified approach to system anchor certificates and black lists. This is then built on in the future to be a comprehensive solution.

Scope

  • Upstream a p11-kit PKCS#11 module is being developed.
  • Upstream a p11-kit tool for extracting certificates in various formats.
  • NSS and p11-kit will have packaging adjustments to use update-alternatives.
  • ca-certificates will have packaging adjustments to replace the legacy file locations for certificate bundle files with symbolic links that point to the combined output.
  • Review will be done of relevant OpenSSL and GnuTLS applications to use the extracted trust information placed in standard locations.

How To Test

Ensure you have at least p11-kit-0.16.3-1 and ca-certificates-2012.87-9 installed

Refer to the separate page with test instructions.

Note: When using applications that load the PKCS#11 p11-kit-trust.so module (for example Firefox and the update-ca-trust command), you can request to dump debug information using an environment variable, like this: 

$ P11_KIT_DEBUG=all firefox

User Experience

Administrators will be able to use a tool to add a certificate authority file to the system trust store and have it recognized by all relevant applications.

Users will stop being surprised by incoherent and unpredictable trust decisions when using different applications with websites/services which require custom trust policy.

Dependencies

  • ca-certificates
  • p11-kit
  • nss
  • gnutls
  • openssl
  • glib-networking
  • ... any relevant applications that are not using the default locations to retrieve certificates.

Contingency Plan

  • It would be easy to back out these changes so that the current (unfortunate) behavior remains.
  • The initial set of changes described by this feature are not invasive. In order to revert behavior, only packaging changes would need to be reverted. (In particular, the ca-certificates package would be reverted to ship static bundle files, and p11-kit-trust would be changed to no longer install the libnssckbi.so with a higher priority.)

Documentation

Release Notes

  • Root anchored certificate authorities are consumed from single location and shared by most applications (unless those applications are explicitly configured with other certificates).
  • A system administrator can now place a non-standard certificate authority to be a trusted root as a file in a directory location. After running a tool, it will be used by most applications (with above caveat), as expected.

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/SharedSystemCertificates&oldid=472952"