Bug 1010047

Summary: vhost frontend plugin gets wrong SSL certs for alias after restore
Product: OpenShift Online Reporter: Rob Millner <rmillner>
Component: ContainersAssignee: Rob Millner <rmillner>
Status: CLOSED CURRENTRELEASE QA Contact: libra bugs <libra-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 2.xCC: bmeng, mfisher, xtian
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-17 13:29:50 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:

Description Rob Millner 2013-09-19 19:17:53 UTC 
Description of problem:

When testing migration from the mod-rewrite plugin to the vhost plugin, an application that had two aliases but only one of which had an SSL cert started using the SSL cert for both aliases.


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


How reproducible:


Steps to Reproduce:
1. Create an app
2. Add two aliases to it
3. Add an SSL cert for one of the aliases
4. curl -k -vvv https://alias1/
5. curk -k -vvv https://alias2/

Actual results:

The SSL cert presented in step 4 was the same as in step 5.

Expected results:

The SSL cert presented in step 4 should not be the same as in step 5.

Additional info:
Comment 1 Rob Millner 2013-09-19 22:36:29 UTC 
Added to pull request: https://github.com/openshift/origin-server/pull/3671
Comment 2 openshift-github-bot 2013-09-20 21:45:00 UTC 
Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/4727cfeb4e02c07a2aa4aa4b07492ce74ad4c356
Bug 1010047 - Change alias handling to that SNI requests do not misroute.
Comment 3 Meng Bo 2013-09-24 09:26:25 UTC 
Checked on devenv_3816, issue still can be reproduced.

# rhc alias-list php1
Alias         Has Certificate? Certificate Added
------------- ---------------- -----------------
foo.bar.com   yes              2013-09-24
foo1.bar1.com no               -

[root@dhcp-10-180 openshiftest]# curl -vvv -k -I https://foo.bar.com/ 
* About to connect() to foo.bar.com port 443 (#0)
*   Trying 54.211.192.94...
* Connected to foo.bar.com (54.211.192.94) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
* 	subject: E=bmeng,CN=BM,OU=OS,O=RH,L=BJ,ST=BJ,C=CN
* 	start date: Mar 29 08:43:20 2013 GMT
* 	expire date: Mar 29 08:43:20 2014 GMT
* 	common name: BM
* 	issuer: E=bmeng,CN=BM,OU=OS,O=RH,L=BJ,ST=BJ,C=CN
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: foo.bar.com
> Accept: */*
> 
< HTTP/1.1 200 OK


[root@dhcp-10-180 openshiftest]# curl -vvv -k -I https://foo1.bar1.com/ 
* About to connect() to foo1.bar1.com port 443 (#0)
*   Trying 54.211.192.94...
* Connected to foo1.bar1.com (54.211.192.94) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
* 	subject: E=bmeng,CN=BM,OU=OS,O=RH,L=BJ,ST=BJ,C=CN
* 	start date: Mar 29 08:43:20 2013 GMT
* 	expire date: Mar 29 08:43:20 2014 GMT
* 	common name: BM
* 	issuer: E=bmeng,CN=BM,OU=OS,O=RH,L=BJ,ST=BJ,C=CN
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: foo1.bar1.com
> Accept: */*
> 
< HTTP/1.1 200 OK


The alias without ssl cert added still can get the SNI setting.
Comment 4 Rob Millner 2013-09-24 20:24:52 UTC 
Works properly on devenv_3819 with both the vhost and mod_rewrite plugins.

[root@ip-10-101-34-46 c]# rhc alias-list php1
Alias         Has Certificate? Certificate Added
------------- ---------------- -----------------
foo.bar.com   yes              2013-09-24
foo1.bar1.com no               -

[root@ip-10-101-34-46 c]# curl -vvv -k -I https://foo.bar.com/
...
* Server certificate:
* 	subject: E=rmillner,CN=foo.bar.com,OU=OpenShift,O="Red Hat, Inc.",L=Mountain View,ST=California,C=US


[root@ip-10-101-34-46 c]# curl -vvv -k -I https://foo1.bar1.com/
...
* Server certificate:
* 	subject: E=root@ip-10-99-29-179,CN=ip-10-99-29-179,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--


However, it was discovered that the fix for this bug broke non-https access to an alias which has an SSL cert associated with it.

[root@ip-10-101-34-46 c]# curl -k -vvv -I http://foo.bar.com/
...
HTTP/1.1 302 Found
...
Location: https://foo.bar.com/app
Comment 5 Rob Millner 2013-09-24 20:51:54 UTC 
Pull request to fix the non-https alias issue.

https://github.com/openshift/origin-server/pull/3698
Comment 6 openshift-github-bot 2013-09-25 02:00:05 UTC 
Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/18682cbc720cf0b1af395852279b6588f8826a99
Bug 1010047 - The http configuration was also needed for an alias with an SSL cert since we get rid of the ServerAlias record for it.
Comment 7 Meng Bo 2013-09-25 08:21:23 UTC 
Checked on devenv_3824, issue fixed. 

Package info:
rubygem-openshift-origin-frontend-apache-vhost.noarch 0:0.1.5-1.git.13.18682cb.el6

The reason I failed in the comment#3 should be I was installing the vhost rpm from the devenv.repo, but the latest change should be in the devenv-local.repo.

$ curl -vvv -s -k -I https://foo1.com/
* Server certificate:
* 	subject: E=bmeng,CN=BM,OU=OS,O=RH,L=BJ,ST=BJ,C=CN

$ curl -vvv -s -k -I https://foo2.com/
* Server certificate:
* 	subject: E=root@ip-10-99-29-179,CN=ip-10-99-29-179,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--

$ curl -vvv -k -I http://foo1.com/
HTTP/1.1 200 OK

$ curl -vvv -k -I http://foo2.com/
HTTP/1.1 200 OK

Move bug to verified.