Bug 223562 - SSL certificate store issues - possible solution (affects ca_root_nss, nss, openssl/base)
Summary: SSL certificate store issues - possible solution (affects ca_root_nss, nss, o...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-09 12:59 UTC by rocky
Modified: 2017-11-22 00:50 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rocky 2017-11-09 12:59:21 UTC
There have been a number of issues raised regarding various difficulties with ca_root_nss and local certificates that should be trusted (see 160387 - certificate store combining local and root certificates; 189811 - missing /etc/ssl/cert.pem (heated discussion over paranoia level required). Basic functionality needs to be provided OOB for users, but but breaking local requirements/policies for certificate trusts needs to be simplified for sysadmin.

A way for these issues to be addressed in a coherent and minimal fashion needs to be provided. Ability for greater functionality and ease of administration is also a bonus. Other platforms have seen the same issue, and many different solutions have been offered; but widely the consensus has been to provide a central store for all certificates systemwide, linking both openssl and nss engines.

As such a proposal is to leave base as is, but where ports are concerned use nss to maintain certificates, and output the trusted to a cert.pem file for openssl/libressl.

Advantages:
- ca_root_nss already uses nss but parses the text source to produce the cert.pem file. Instead of covert use we're switching to overt. (Curl uses the same - but can use nss)
- sysadmins can "trust" which certificates they want - even from the mozilla ROOTS
- updates to the root list will occur via the libnssckbi.so file and not interfere with local trusted certificates
- possible (currently experimental?) bridge between openssl and nss certificate store
- a central store could mean user apps such as firefox could automatically trust local certificates as they can be set to use a shared database directly or imported from the system db

Disadvantages:
- could be slightly more space required for nss
- number of ports dependent on ca_root_nss will need to be adjusted - what to test when dependency checking?

nss certificate store db can placed anywhere in theory (firefox/thunderbird use profile dirs), but theoretical "default" is suggested to be /etc/pki/nssdb. In line with freebsd convention, ${LOCALBASE}/etc/pki/nssdb would be best.

This would mean the nss port would be required to trigger creation of the db using modutil -create -dbdir sql:${DB}, an option to use libnssckbi.so using modutil -dbdir ${DB} -add ca_roots -libfile ${LOCALBASE}/lib/nss/libnssckbi.so (or the p11-kit equivalent), and either an option (default on) to create cert.pem of _all_ trusted certificates in /usr/local/etc/ssl, with a symlink to /etc/ssl, or port (replace ca_root_nss?) to complete. (Preference would be an option in nss - port that doesn't install anything wouldn't make sense in the infrastructure).

Creation of the cert.pem file is then as easy as piping and outputting the following to cert.pem:

#!/bin/sh

# accept output from: certutil -d sql:${db} -L -h all | grep "\([CPTu]\{0,3\},\)\{2\}[CPTu]\{0,3\}" | sed 's/\([CPTu]\{0,3\},\)\{2\}[CPTu]\{0,3\}//' | trusted_certs.sh > cert.pem && certutil -d sql:${db} -L | grep "\([CPTu]\{0,3\},\)\{2\}[CPTu]\{0,3\}" | sed 's/\([CPTu]\{0,3\},\)\{2\}[CPTu]\{0,3\}//' | trusted_certs.sh >> cert.pem

db = "sql:${LOCALBASE}/etc/pki/nssdb" # this could be better to use make env

while read input; do
    certutil -d $db -L -n "$input"
    certutil -d $db -L -a -n "$input"
done
Comment 1 Tilman Keskinoz freebsd_committer freebsd_triage 2017-11-21 13:56:31 UTC
The bugtracker is the wrong place to discuss a solution. First there should be some consensus on a mailinglist and then a patch can be implemented and submitted to the bugtracker.
Comment 2 rocky 2017-11-22 00:50:36 UTC
Well if it makes any difference I'm testing a patch now.
As for discussion that has been deathly silent - how can any discussion to reach some consensus be had on a mailing list that sees such little traffic? In fact the most discussion on this subject has been had on here through other bugs.