Bug 220511 - security/ca_root_nss: Add port option to remove duplicate certs based on Subject
Summary: security/ca_root_nss: Add port option to remove duplicate certs based on Subject
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Jochen Neumeister
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2017-07-06 12:52 UTC by Jim Pirzyk
Modified: 2023-09-02 11:12 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (ports-secteam)


Attachments
Patch to add make option (2.86 KB, patch)
2017-07-06 12:52 UTC, Jim Pirzyk
no flags Details | Diff
Patch to add make option (Fixed typo) (2.85 KB, patch)
2017-07-11 12:35 UTC, Jim Pirzyk
no flags Details | Diff
Updated patch (2.93 KB, patch)
2019-02-16 00:42 UTC, Jim Pirzyk
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Pirzyk freebsd_committer freebsd_triage 2017-07-06 12:52:31 UTC
Created attachment 184124 [details]
Patch to add make option

The current ca_root_nss package will bundle up certificates based on their Subject and Serial, this works well for most packages but it does present a problem for OpenVPN.  OpenVPN insists only on unique Subjects, see https://forums.freebsd.org/threads/60254/

Currently StartSSL has two certs in ca_root_nss, Serial 0 and 45.  They represent SHA1 and SHA256.  The attached patch will use Serial 45 cert and ignore the SHA1 cert (based on larger Serial Numbers).

Ideally the solution is to get OpenVPN to properly handle multiple CAs with the same Subject line (using the Serial) but until then, this is plausable workaround.  This option is not on by default.
Comment 1 Mark Felder freebsd_committer freebsd_triage 2017-07-06 13:02:05 UTC
One could argue that StartSSL should just be blacklisted entirely, but on the other hand I'm also very wary of distributing any version of ca_root_nss that has been modified in any way.


I'd like to hear input from other ports-secteam@ members
Comment 2 Jason Unovitch freebsd_committer freebsd_triage 2017-07-09 00:12:26 UTC
I concur that I'm a bit weary to distribute a modified ca_root_nss port by default. I feel we should remain without bias on what upstream is providing.

However for an off by default option this does look like a viable workaround for the bug. I would like to see this reported to the OpenVPN folks first before making a modification like this particularly if OpenVPN is the only software impacted by this.

On the purely technical side from a cursory look at the patch the NODUPS_CONFIGURE_ON looks far too close to a port "option helper" when it is just used as an environmental variable. Seeing it wrapped in the PORT_OPTION check threw me for a bit. I would change that and fix the "ingnoring" typo at a minimum.
Comment 3 Jim Pirzyk freebsd_committer freebsd_triage 2017-07-11 12:35:12 UTC
Created attachment 184255 [details]
Patch to add make option (Fixed typo)
Comment 4 Jim Pirzyk freebsd_committer freebsd_triage 2017-07-11 12:37:50 UTC
OpenVPN Bug report https://community.openvpn.net/openvpn/ticket/913
Comment 5 Jochen Neumeister freebsd_committer freebsd_triage 2019-02-15 18:18:22 UTC
what is the current status?
Does ports-secteam have to be active here?
Comment 6 Jim Pirzyk freebsd_committer freebsd_triage 2019-02-15 19:07:50 UTC
OpenVPN closed the bug report as not a bug.  They do not recognize the need to have multiple Subject entries in the ca_root_nss file.  While removing StartSSL would get around the issue, it doesn't solve the underlying problem.

The basic question here is "Is having duplicate Subject lines in the ca_root_nss file accept and supported?"  and if so, "What do we do with applications that do not (or will not) support such a configuration?"
Comment 7 Jochen Neumeister freebsd_committer freebsd_triage 2019-02-15 19:17:28 UTC
Your patch should fix that in FreeBSD, right? Unfortunately he is 2 years old. Can he still be used? (I did not test it)
Comment 8 Jim Pirzyk freebsd_committer freebsd_triage 2019-02-16 00:42:56 UTC
Created attachment 202060 [details]
Updated patch
Comment 9 Walter Schwarzenfeld freebsd_triage 2019-08-13 11:18:09 UTC
ping!
Comment 10 Jim Pirzyk freebsd_committer freebsd_triage 2019-08-17 14:40:50 UTC
(In reply to Walter Schwarzenfeld from comment #9)

What are we pinging here?  I have submitted an updated patch.
Comment 11 Michael Osipov 2020-05-20 19:43:28 UTC
There is nothing wrong having more than one cert with the same subject. I can present two public ones (CA certs) for this case. One with SHA-1, the other with SHA-256, both are still valid have validate sub certs. Throwing them out is wrong for me.
Comment 12 Jim Pirzyk freebsd_committer freebsd_triage 2020-05-20 19:56:03 UTC
I 100% agree here.  The problem is when certain applications do not properly handle multiple certs (openvpn for example).  I only added this option as a way to get around the shortcoming of those apps.  I would not want this option to be the default.
Comment 13 Jochen Neumeister freebsd_committer freebsd_triage 2020-07-23 16:56:54 UTC
The question I'm asking myself is this:
If OpenVPN says this is not a bug, so not a bug, then why should we change it here? The point is that you can manage multiple certificates.

Michael and Jim are for changing it in FreeBSD anyway, right?

Are there any other opinions?

I am for not changing it, but I am open to other opinions.
Comment 14 Michael Osipov 2020-07-24 13:54:44 UTC
(In reply to Jochen Neumeister from comment #13)

I do not consider that the port must be changed to fix an issue with OpenVPN. Rather this needs to addressed somehow else. I think that soon certctl(8) will be in place, the user has full control over certs in /etc/ssl/certs/ with blacklists and can safely block certs with subject name collision. After 12.2 and 11.4 I see no need for security/ca_root_nss at all, imho.
Comment 15 Kubilay Kocak freebsd_committer freebsd_triage 2022-04-27 10:16:55 UTC
^Triage Reset assignee (timeout; 6 months), leave in CC (port maintainer)
Comment 16 Jochen Neumeister freebsd_committer freebsd_triage 2023-09-02 11:12:54 UTC
No activity for 3 years. I close here. If there are any questions or problems, feel free to reopen it.