Bug 719401

Summary: There is now way to configure the list of acceptable CA's for client authentication
Product: Red Hat Enterprise Linux 7 Reporter: Dmitri Pal <dpal>
Component: mod_nssAssignee: Matthew Harmsen <mharmsen>
Status: CLOSED WONTFIX QA Contact: Kaleem <ksiddiqu>
Severity: low Docs Contact:
Priority: low    
Version: 7.0CC: dpal, nkinder, rcritten, wolter.eldering
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 637365 Environment:
Last Closed: 2018-04-16 20:39:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 637365    
Bug Blocks:    

Description Dmitri Pal 2011-07-06 17:53:31 UTC
+++ This bug was initially created as a clone of Bug #637365 +++

Created attachment 449572 [details]
add AcceptableCANames option

Description of problem:
mod_nss will accept all certificates from CA's trusted in the certificate database. There is now way to configure that per server.

Version-Release number of selected component (if applicable):
1.0.8

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
All trusted CA names (for SSL) are sent during Client Certificate Requests

Expected results:
The user of mod_nss can control the list sent by apache configuration

Additional info:
The patch included let's the user control the list using:
AcceptableCANames "rfc1845 name" "rfc1845 name"

If this configuration option is omitted all trusted names are sent.
The supplied list is used the filter the CA's in the certificate database.

The code in nss_hook_pre_connection is added as a workaround for: https://bugzilla.mozilla.org/show_bug.cgi?id=597028

--- Additional comment from rcritten on 2010-09-27 10:50:16 EDT ---

I assume an rfc1845 name is an NSS nickname? RFC 1845 is an experimental SMTP extension as far as I can tell.

There is a commented-out block of code starting with:
/* we only wan't to do this onece not for every server */

This doesn't need to be here at all, right?

It looks like this patch mixes in some changes you had submitted in bug 635324, is that right?

Should the error that is printed from "CERT_LIST_EMPTY(ca_certs)" really say something like "acceptable certificates not found in NSS database or something?" It looks like it would be possible to add a CA that doesn't exist in the database as long as you configure at least one that does.

--- Additional comment from wolter.eldering.cn on 2010-09-27 11:18:04 EDT ---

The rfc1845 name is the Subject of the certificate, see CERT_FilterCertListByCANames in certvfy.c

Yes the comment can be removed.

You're right that's also included, I'll attach a new patch on top of the one for bug 635324.

In this patch at least one of the certificates named (by subject) should be in the database as a trusted ca for SSL.

An alternative would be to check if the list after filtering has the same length as the list of acceptable CA's specified. In that way all of the acceptable CA's listed in the option must be in the database.

--- Additional comment from wolter.eldering.cn on 2010-09-27 22:57:23 EDT ---

Created attachment 450077 [details]
add AcceptableCANames option

Processed remarks

--- Additional comment from dpal on 2011-07-06 13:52:47 EDT ---

The patch will be accepted upstream and will be delivered as a version that will be included into RHEL7.

Comment 5 Matthew Harmsen 2016-01-05 22:43:32 UTC
Based on similar issues discussed with rcritten, moving this bug from RHEL 7.3 --> RHEL 7.4.

Comment 10 Matthew Harmsen 2018-04-16 20:39:34 UTC
As the mod_nss component is being deprecated in the next major release of RHEL, and since there is simply not strong enough demand for fixing this issue in RHEL 7.x, it has been determined that this bug will be CLOSED WONTFIX at this point in time.