Bug 1010047 - vhost frontend plugin gets wrong SSL certs for alias after restore
vhost frontend plugin gets wrong SSL certs for alias after restore
Status: CLOSED CURRENTRELEASE
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
2.x
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Rob Millner
libra bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 15:17 EDT by Rob Millner
Modified: 2015-05-14 19:28 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-17 09:29:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rob Millner 2013-09-19 15:17:53 EDT
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 18:36:29 EDT
Added to pull request: https://github.com/openshift/origin-server/pull/3671
Comment 2 openshift-github-bot 2013-09-20 17:45:00 EDT
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 05:26:25 EDT
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@redhat.com,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@redhat.com,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@redhat.com,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@redhat.com,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 16:24:52 EDT
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@redhat.com,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 16:51:54 EDT
Pull request to fix the non-https alias issue.

https://github.com/openshift/origin-server/pull/3698
Comment 6 openshift-github-bot 2013-09-24 22:00:05 EDT
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 04:21:23 EDT
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@redhat.com,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.

Note You need to log in before you can comment on or make changes to this bug.