Bug 1379823

Summary: mod_nss SNI serves incorrect certificate
Product: Red Hat Enterprise Linux 6 Reporter: Robert Bost <rbost>
Component: mod_nssAssignee: Matthew Harmsen <mharmsen>
Status: CLOSED ERRATA QA Contact: Kaleem <ksiddiqu>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.9CC: akasurde, dpal, nkinder, rbost, rcritten
Target Milestone: rc   
Target Release: 6.9   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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]
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-21 09:07:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Candidate patch to fix initialization issue
none
console.log none

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