RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1379823 - mod_nss SNI serves incorrect certificate
Summary: mod_nss SNI serves incorrect certificate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mod_nss
Version: 6.9
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 6.9
Assignee: Matthew Harmsen
QA Contact: Kaleem
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-27 18:27 UTC by Robert Bost
Modified: 2019-12-16 06:55 UTC (History)
5 users (show)

Fixed In Version: mod_nss-1.0.10-8.el6
Doc Type: Bug Fix
Doc Text:
Each virtual host (VH) including mod_nss SNI was serving the incorrect certificate because its default initialization was FALSE rather than UNSET so each VH was not inheriting the global value; this patch corrects this issue by establishing a default value of UNSET rather than FALSE. [BZ #1379823]
Clone Of:
Environment:
Last Closed: 2017-03-21 09:07:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Candidate patch to fix initialization issue (1.00 KB, patch)
2016-10-17 18:51 UTC, Rob Crittenden 		no flags Details | Diff
console.log (6.10 KB, text/plain)
2016-11-29 09:58 UTC, Abhijeet Kasurde 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2677861 0 None None None 2016-09-30 18:01:36 UTC
Red Hat Product Errata RHBA-2017:0576 0 normal SHIPPED_LIVE mod_nss bug fix update 2017-03-21 12:23:29 UTC

Description Robert Bost 2016-09-27 18:27:19 UTC 
Description of problem:
When using SNI with mod_nss, the DocumentRoot from correct VHost is served up but the wrong certificate is provided. Seems like mod_nss is pulling whatever the first VHost's NSSNickname is. When I change up NSSNickanme on the very first matching VHost, it also changes cert sent to client.


Version-Release number of selected component (if applicable): mod_nss-1.0.10-6.el6.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Create two different VHosts with two different certificates. For example:

Listen 443
NSSEnforceValidCerts off
NameVirtualHost *:443

<VirtualHost *:443>
  ServerName server1
  NSSEngine On
  NSSNickname server1
  NSSCertificateDatabase /etc/httpd/nss/alias
  DocumentRoot /var/www/html/server1
</VirtualHost>

<VirtualHost *:443>
  ServerName server2
  NSSEngine On
  NSSNickname server2
  NSSCertificateDatabase /etc/httpd/nss/alias
  DocumentRoot /var/www/html/server2
</VirtualHost>

2. curl -vk https://server1/
   curl -vk https://server2/
3. Compare the Server Certificate's SN in each request.

Actual results:
Wrong certificate returned to client. 

Curl output showing same certificate being used.

# curl -vk -o /dev/null https://server1/ 2>&1 | grep subject
* 	subject: CN=server1,O=RedHat,L=Westford,ST=MA,C=US
# curl -vk -o /dev/null https://server2/ 2>&1 | grep subject
* 	subject: CN=server1,O=RedHat,L=Westford,ST=MA,C=US


Expected results:
https://server1/ returns certificate from nssdb with nickname server1
https://server2/ returns certificate from nssdb with nickname server2


Additional info:
NSS DB listing for certificates being used in example:

# certutil -L -d /etc/httpd/nss/alias/ -n server1 | grep Subject
        Subject: "CN=server1,O=RedHat,L=Westford,ST=MA,C=US"
        Subject Public Key Info:
# certutil -L -d /etc/httpd/nss/alias/ -n server2 | grep Subject
        Subject: "CN=server2,O=RedHat,L=Westford,ST=MA,C=US"
        Subject Public Key Info:

Correct pages served up:
# curl -vk https://server2/ 2>&1 | tail -n2

this is server 2
# curl -vk https://server1/ 2>&1 | tail -n2

this is server 1
Comment 3 Robert Bost 2016-09-30 17:51:34 UTC 
The only workaround at this point is to specify a different IP address in each VirtualHost instead of using *:443.

# egrep 'VirtualHost|ServerName' /etc/httpd/conf.d/nss.conf 
NameVirtualHost *:443
<VirtualHost 127.0.0.1:443>
 ServerName server1
</VirtualHost>
<VirtualHost 192.168.122.132:443>
  ServerName server2
</VirtualHost>
# curl -vk https://server1/ 2>&1 | grep subject
* 	subject: CN=server1,O=RedHat,L=Westford,ST=MA,C=US
# curl -vk https://server2/ 2>&1 | grep subject
* 	subject: CN=server2,O=RedHat,L=Westford,ST=MA,C=US
Comment 4 Robert Bost 2016-10-03 15:27:43 UTC 
Upstream mod_nss-1.0.14 does not appear to be affected by this issue.
Comment 5 Robert Bost 2016-10-03 15:42:20 UTC 
Upstream mod_nss-1.0.12 does not appear to be affected by this issue.
Comment 6 Rob Crittenden 2016-10-03 19:48:16 UTC 
Pretty easily reproducible but logging is lacking so not obvious what is going on. Given it works in 1.0.12 (confirmed) I can only assume a problem in the backport.

Can you update the KB to mention that this affects only RHEL 6?
Comment 7 Robert Bost 2016-10-03 20:00:59 UTC 
The article has been updated.
Comment 8 Rob Crittenden 2016-10-03 20:37:06 UTC 
The important difference between 1.0.10 and 1.0.12 is that SNI is disabled by default in 1.0.10.

Try adding NSSSNI On to each of your VirtualHost and that should fix it.
Comment 9 Robert Bost 2016-10-04 16:18:59 UTC 
Works on my end. I'm awaiting customers to confirm in their setup too. 

I would consider this a workaround though. The NSSSNI setting has an RSRC_CONF scope so if it is set to On the server config, shouldn't that fall down into VHosts? This type of behavior is present in upstream mod_nss-1.0.12 (didn't test with anything later).
Comment 10 Rob Crittenden 2016-10-04 19:13:02 UTC 
I believe what is happening is that the default is FALSE rather than UNSET so each VH gets initialized as FALSE so doesn't inherit the global value.
Comment 11 Rob Crittenden 2016-10-17 18:51:35 UTC 
Created attachment 1211497 [details]
Candidate patch to fix initialization issue
Comment 13 Abhijeet Kasurde 2016-11-29 09:45:09 UTC 
Verified using mod_nss version ::
mod_nss-1.0.10-9.el6.x86_64

Please find the attachment for verification steps.
Comment 14 Abhijeet Kasurde 2016-11-29 09:58:35 UTC 
Created attachment 1225764 [details]
console.log
Comment 16 errata-xmlrpc 2017-03-21 09:07:43 UTC 
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.

https://rhn.redhat.com/errata/RHBA-2017-0576.html
Note You need to log in before you can comment on or make changes to this bug.