I've changed nss_engine_kernel.c around line 629 to use CERT_NameToAscii instead of CERT_GetCommonName, and to put a slash on the beginning of the string first. This makes the spoof check useful again, and ensures that the whole DN is used in authorization, so certificates having the same common name but different issuers will not produce wrong authorization results.

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Your suggestion in #c2 seems fine to me. sslconn->client_dn is only used for FakeBasicAuth so we can do what we wish with it.

Created attachment 498352 [details]
Use full subject for FakeBasicAuth, always retrieve the client cert

The first fix is to retrieve the full certificate subject instead of just the CN for FakeBasicAuth and prefix it with / to be compatible with OpenSSL.

The second always attempts to retrieve the client certificate in nss_hook_ReadReq().

Created attachment 498379 [details]
Revised patch, only get cert in nss_hook_ReadReq()

Thank you, sir: this patch fixes both of the problems I've had with mod_nss.

Committed upstream a6c3370491ae1d3bc552e8de9353c82f73e510e3

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, client certificates were only retrieved during the initial SSL handshake if the NSSVerifyClient option was set to "require" or "optional". Also, the FakeBasicAuth option only retrieved Common Name rather than the entire certificate subject. Consequently, it was possible to spoof an identity using that option. This bug has been fixed, the FakeBasicAuth option is now prefixed with "/" and is thus compatible with OpenSSL, and certificates are now retrieved on all subsequent requests beyond the first one.

Created attachment 532763 [details]
nss.conf used to test mod_nss

VERIFIED.

Version Info.
=======================================
[root@dhcp201-108 conf.d]# rpm -q mod_nss
mod_nss-1.0.8-13.el6.x86_64
[root@dhcp201-108 conf.d]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 Beta (Santiago)
[root@dhcp201-108 conf.d]# 
=======================================

Procedure:

1/ Have a Certificate Authority instance handy. I used a Certificate System CA instance located on MachineA

2/ On MachineB : # yum install mod_nss

3/ On MachineB,  Add nss-test.conf to /etc/httpd/conf.d/ (attached in comment #11)

3.1/ Also ensure to include the nss-test.conf in httpd.conf
=======================================
[root@dhcp201-108 conf.d]# grep "Include conf" /etc/httpd/conf/httpd.conf 
#Include conf.d/*.conf
Include conf.d/nss-test.conf
[root@dhcp201-108 conf.d]# 
=======================================

4/ Add the CAs (from MachineA) 'Signing Cert' and 'Server Cert' into /etc/httpd/alias on MachineB (where mod_nss is configured)
=======================================
[root@dhcp201-108 alias]# certutil -L -d /etc/httpd/alias/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

cacert                                                       CTu,Cu,Cu
Server-Cert                                                  u,u,u
Server-Cert cert-pki-ca-aug24-qeb                            u,u,u
caSigningCert cert-pki-ca-aug24-qeb                          CT,C,C
alpha                                                        u,pu,u
[root@dhcp201-108 alias]# 
=======================================

5/ Ensure to include the nss-test.conf

[root@dhcp201-108 conf]# grep "Include conf" httpd.conf 
#Include conf.d/*.conf
Include conf.d/nss-test.conf
[root@dhcp201-108 conf]# 


6/ Create a test html file in /var/www/html
=======================================
[root@dhcp201-108 html]# mkdir securearea ; cd securearea
[root@dhcp201-108 securearea]# cat index.html 
<html>
        <head>
                <title>mod_nss secure area</title>
        </head>
        <body>
                <h1>Red Hat Enterprise Linux</h1>
                +mod_nss secure area
        </body>
</html>

[root@dhcp201-108 securearea]# 
=======================================


7/ Restart httpd on MachineB (where mod_nss is configured)
=======================================
[root@dhcp201-108 alias]# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
[root@dhcp201-108 alias]# 
=======================================

8/ Issue a user certificate from the CA and import it into the browser.

9/ Now from the browser, try to access the 'securearea' url

http://MachineB:7443/securearea

Authentication for client certificate should be prompted, and httpd 'access_log' should have the entries

Reload the above url  a few times, now, every reload the should reflect the auth in the access_log

Thanks Rob. for detail.

Successful httpd access_log entries:
#######################################
==> /var/log/httpd/access_log <==
10.16.76.34 - - [10/Nov/2011:03:51:31 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23"
10.16.76.34 - - [10/Nov/2011:03:51:47 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23"
10.16.76.34 - - [10/Nov/2011:03:52:05 -0500] "GET /securearea/ HTTP/1.1" 200 146 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-2.el5_7 Firefox/3.6.23"
#######################################

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1656.html