I make this PR because I cannot contact the port maintainer. Tried emailing the "FreeBSD GEKO Team" - geko@freebsd.org. The email bounced, was never delivered. Problem: For ca_root_nss there is no /etc/ssl/cert.pem symlink created by default. The PKGNG built pkg of ca_root_nss doesn't create the necessary /etc/ssl/cert.pem file. Most people think "ah" now i know! i'll just "pkg install ca_root_nss". Yet the result simply does not work. It is infuriating, frustrating, and confusing for newcomers. No other operating system does this... If i'm on Windows, Mac, Linux, recognizing the ssl certs "just works". "ca_root_nss" is the only pkg that FreeBSD users are commonly aware of, and will actually install. So it's rather absurd because no alternative or competing SSL cert pkg (that anybody is aware of) is being installed to that same location. For a "non-default-option", the usualy proceedure to build from ports (manually enabling the ETCSYMLINK option by typing "make config") is also a fail. Because compiling that port pulls in huge perl5 build dependency. For the sake of 1 symlink "ln -s" is utterly absurd - when it can install as pkg instead from pkgng repository. Fix: Solution: Make ETCSYMLINK the default build option. Problem goes away. Patch file included. Patch attached with submission follows: How-To-Repeat: pkg install ca_root_nss Invalid ssl certs.
Class Changed From-To: maintainer-update->change-request Fix category (submitter is not maintainer) (via the GNATS Auto Assign Tool)
Responsible Changed From-To: freebsd-ports-bugs->gecko Over to maintainer (via the GNATS Auto Assign Tool)
gecko@ cannot just decide to trust the provided CA list by default. This needs an approval from secteam as the option affects any base component or port that uses OpenSSL from base.
I want to point out that this package was explicitly created because secteam / freebsd security officer did not want to vouch for any certificate bundle. Personally I only think a link like this should be set up after explicitly asking a user if it's OK, while pointing out that there is NO guarantee of the certificates being installed. Installing the link by default on package install seems like a really bad idea as this package might be pulled in as a dependency in which case a user unknowingly installs a certificate bundle that other programs might pick up.
would be to have some mechanism, whereby alternative pkg could be installed(In reply to Simon L. B. Nielsen from comment #4) > I want to point out that this package was explicitly created because secteam > / freebsd security officer did not want to vouch for any certificate bundle. Great. Then 3rd party pkgs / ports explicitly aren't part of base, and aren't in the remit of sec team. So you can actually do this (if you wish). > Personally I only think a link like this should be set up after explicitly > asking a user if it's OK, while pointing out that there is NO guarantee of > the certificates being installed. I'm not sure the vast majority of users agree with such a paranoid stance. The reality is that certs work very well, and have done for quite some time. OTOH I do agree that it would help if a mechanism to ask such questions were added to pkgng itself. But at this time there is no such alternative. > … <more security-related paranoia) ... If indeed there is actually such little confidence in this port, like you are making out, which i really don't believe for a second. Then another way is to give users a choice as to which cert bundle to install. Either this *or* (that conflicts) an alternative pkg/port that does put there the needed /etc/ symlink as it's default setting. For example: CURL's pre-bundled Mozialla CERTs are from the same source. They may not be updated quite at the same time, i'm not sure. But they are pre-bundled and can just be fetched from the Curl website. One advantage of the CURL certs is that since they are pre-bundled, no need for any Perl Build dependancy. (as unfortunately this port has). Otherwise it wouldn't be such hassle to build ca_root_nss from ports.
IMHO, it is sane to say "FreeBSD follows Mozilla's policy w.r.t. to certs and will, by default, trust certs that Mozilla does as well." This is a little less paranoid than we have said in the past, but makes for a much better user experience.
this PR status is set to "Approval Needed". After reading through it, it seems like it should be reset to "In discussion" or something. I don't see a pending patch. (It's showing up a search looking for delinquent approvals)
I have a similar proposal at http://lists.freebsd.org/pipermail/freebsd-security/2014-July/007811.html .
Moving to in-discussion.
(In reply to John Marino from comment #7) > I don't see a pending patch. It's the file.txt attachment. This is harming real-world security to feed the imaginations of tin-foil-hat paranoids. Users need a sane CA database. Maybe OpenSSL configuration should include /usr/local/share/certs/ in the default trust DB? If you don't want to trust ca_root_nss certs, don't install it or de-configure that as a search path.
I'm a strong +1 on this. Additionally, I'd like to see a second symlink created by ca_root_nss, to support the ports version of OpenSSL in addition to the base version, which both use the same default CAFile name in their configuration. Among many other good reasons to do this, Python has recently moved to verify certificates by default [1][2], which are now causing tests (and runtime functionality) to fail due to the missing root certificates (symlinks). In order to address the concern regarding the perceived assurance of trust, I believe a post-installation message notifying uses of possible implications and lack of warranty is sufficient. [1] http://legacy.python.org/dev/peps/pep-0476/ [2] http://bugs.python.org/issue22417
Copy-paste from the discussion on freebsd-security@: Xin Li <delphij@delphij.net> writes: > Currently, FreeBSD does not install a default /etc/ssl/cert.pem > because we do not maintain one ourselves. [...] So my proposal would > be: > > 1. Import a set of trusted root certificates, and install if > MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; At a minimum, we need the certificate chain for all freebsd.org certificates. > 2. In src/etc/Makefile, automatically create a symbolic link if it's > not already present in ${DESTDIR}/etc/ssl; > > 3. Teach mergemaster(8) and other similar applications to create the > symbolic link on demand; > > 4. Change the install/deinstall behavior of security/ca_root_nss: > ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on > install then overwrite with new symlink, and restore on deinstall. > ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist, > install new a symlink; on deinstall, if > /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a > symlink to there, or remove if the file does not exist. I would prefer to have each port install their certificate lists in a "hidden" location which is then added to the search path using c_rehash. This may require changing libfetch and various applications to pass a path to SSL_CTX_load_verify_locations() instead of or in addition to a file. DES -- Dag-Erling Smørgrav - des@des.no
Is this some joke I am not in on? Just add the symlink already. This is completely unacceptable for user experience of FreeBSD. Not only that, but it actively encourages people to be less secure because they will just use '--disable-cert-check' or whatever command line tool offering disables the check. The fact that this has been in discussion and still unresolved since May is completely unacceptable and frankly embarrassing. I will commit this fix in the next 24 hours unless someone has a *real* reason to block this. I like Xin's proposal as well and will be fine if he reverts my change when his code is ready for the base system.
I wasn't aware of this until my python scripts started failing recently and I stumbled upon this bug. I've since signed up for this bugzilla and am trying to be more involved.
+1
Reset assignee per comment 4. And drop "security" keyword for the issue isn't tied to any (potential) vulnerability.
The symlink was added to the ca_root_nss port in r378720 on 2015-02-09, as a stopgap measure. I still stand by what I wrote in comment 12 and will try to implement this during the summer.
(In reply to Dag-Erling Smørgrav from comment #18) As you're probably aware, my commit in 378720 only covered OpenSSL from ports (which looks in the LOCALBASE location). It did not cover OpenSSL in *base* for consuming software using the SSL_CTX_load_verify_locations function. ETCSYMLINK still needs to be turned on as a default option (the intent and spirit of this issue) in the short-term until we have the infrastructure in place to do better or with greater granularity I was just about to assign this issue to myself for resolution, so if you'd like to re-assign it, we can create a separate issue for the additional implementation
@koobs I suggest you just commit the ETCSYMLINK change and leave the bug assigned to me.
(In reply to Dag-Erling Smørgrav from comment #20) Roger that, stand by.
A commit references this bug: Author: koobs Date: Sat Jun 6 07:41:52 UTC 2015 New revision: 388657 URL: https://svnweb.freebsd.org/changeset/ports/388657 Log: security/ca_root_nss: Enable certificate verification (for Base OpenSSL) Enable the ETCSYMLINK option so that SSL certificate verification is enabled by default for OpenSSL in base. This change is the third in a set of changes [1][2] that improves the default configuration and behaviour of client software relying on OpenSSL for SSL/TLS and certificate verification. A symlink is installed which points to the root certificate bundle in the location that OpenSSL in base looks for them, as configured at build time [2]. This allows any and all software utilising SSL_CTX_load_verify_locations function to verify SSL certificates by default after installation of this package. [1] https://svnweb.freebsd.org/changeset/ports/372629 [2] https://svnweb.freebsd.org/changeset/ports/378720 PR: 189811 196357 Requested by: many Submitted by: dreamcat4 gmail com Approved by: maintainer timeout (>1 year) Changes: head/security/ca_root_nss/Makefile
No longer blocking bug 196357. This issues summary now requires changing to account for the additional changes and extensions to certificate infrastructure going forward. @des, please update the summary according to your needs.
I can say that this works really nice. Why is this ticket still open? Though, I do not understand who copies /usr/local/openssl/cert.pem. The Makefile has no copy command. Can someone enlighted me?
This issue was left open to continue on to possible base PKI features mentioned in comment 12 and comment 14. It should have instead be closed, given the issue as originally reported, has been resolved. Given no movement, reass0gin to me given I committed the change that added support for base OpenSSl to see ca_root_nss certificates. Any features relating to extending base PKI should be created in new issues
"Comment 14" was supposed to read Comment 18. See also comment 20
By all means, let's just shove the entire discussion under a rug just because a temporary solution was committed.
(In reply to Dag-Erling Smørgrav from comment #27) Sarcasm is not necessary, please keep discussions on the issue tracker civil and respectful. Closing the issue is not an attempt to hide anything under a rug, as was explained in comment 25 and more explicitly below: 1) The issue was resolved as per original report (and summary) 2) No changes were made to reflect the future intent of the issue for 1 year 3) Related but separate issues that arise out of discussion on a bug should be tracked in separate (possibly dependent) issues to avoid ambiguity of who is/was involved, in what and when. Having said that, in order to avoid continuation of a bug re-assignment war, I will update this summary of, and re-categorize the issue for you so it reflects what is intended now.