Description of problem:
In the installation scripts and deployment guide, we do not change the ServerName setting for the broker's Apache from the default of 'localhost'. Consequently, the TLS handshake raises a warning alert. This warning alert can cause JBoss Developer Studio to report an authentication failure.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install a new broker host and a new node host using the installation scripts under <https://github.com/openshift/openshift-extras/blob/enterprise-1.1/enterprise/install-scripts/> (for OSE 1.1), the scripts under <https://github.com/openshift/openshift-extras/blob/enterprise-1.2/enterprise/install-scripts/> (for OSE 1.2), or the deployment guide at <https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/1/html-single/Deployment_Guide/index.html>.
2. Run `httpd -S` on the broker host.
3. Run `tcpdump -lnni eth0 -w /tmp/tcpdump.out tcp port 443` on the broker host, run `curl -k https://broker.example.com/broker/rest/api` on a host that is remote to the broker, and run Wireshark on the resulting tcpdump.out file.
In Step 2, the `httpd -S` output shows 'localhost' for the virtual servers.
In Step 3, Wireshark shows "TLSv1 Alert (Level: Warning, Description: Unrecognized Name), Server Hello, Certificate" in the TLS handshake of every new connection.
In Step 2, the `httpd -S` output should show the configured hostnames for the virtual servers.
In Step 3, Wireshark should not show any warnings or errors in the TLS handshake.
Back in November/December, we discussed how to set NameVirtualHost, ServerName, and ServerAlias in the broker's Apache configuration for the broker so as to have the broker respond to requests directed to it as well as to live harmoniously with the node's Apache instance, should the broker and node be installed on the same host. Part of the discussion is in bug 876324.
The outcome of the discussion is that the current installation scripts delete the VirtualHost stanza from the ssl.conf that ships with mod_ssl, and we have "ServerAlias localhost" and "ServerName localhost" in Apache conf.d files that ship with the OpenShift packages for both the node and the broker. (ServerName is in a separate configuration file to make it easier for sysadmins to change the ServerName setting, but we do not instruct sysadmins to change the setting—we just say, "Feel free to change this as desired" in a comment in the configuration file.)
The effect of the current default configuration is that we sometimes get warnings from Apache when it starts, but things generally work properly, with the broker and node responding to requests without either one taking HTTP connections that are supposed to go to the other.
An additional, undesirable effect of leaving ServerName set to localhost is that Java Developer Studio reports that credentials are invalid. A user reports that with debugging enabled, Apache reports "No matching SSL virtual host for servername foo.com found (using default/first virtual host)," and Wireshark shows "unrecognized name" in the SSL Hello handshake. This user reports that he saw the problem with JBoss Developer Studio using OpenJDK 6, Oracle JDK 6, and OpenJDK 7 and that the problem goes away when ServerName is changed to the host's external host name.
As shown above, I have verified that Wireshark shows "TLSv1 Alert (Level: Warning, Description: Unrecognized Name), Server Hello, Certificate" when I hit /broker/rest/api on a test broker from a recent OSE-1.2 puddle and that the warning goes away when I change ServerName to broker.example.com on my test broker.
So it looks like our configuration will cause a warning with TLS (a little bad), and JDS treats the TLS warning as a fatal error in authentication (really bad).
A similar problem with Java 1.7 and TLS is reported here: http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0
A bug report against the JDK was filed with Oracle for treating the warning as a fatal error by default, but that bug report has been closed as "Not an Issue": http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374
Should we fix this with a combination of documentation and an oo-accept-broker check?
I would suggest documentation, oo-accept-broker, and the installation scripts in openshift-extras as well.
Krishna's Puppet module for Origin already sets ServerName: https://github.com/openshift/puppet-openshift_origin/blob/master/templates/broker/broker_servername.conf.erb
Pull request to update install scripts to set ServerName to the hostname for broker and nodes.
It's pretty hard to check in oo-accept-broker that the ServerName is *correct*. We could pretty easily check that it's not the default localhost, though.
Updates to oo-diagnostics:
Updates to install script:
Commit pushed to master at https://github.com/openshift/origin-server
<oo-diagnostics> Bug 970805 - Add check for broker SSL cert
Add a test for verifying that the broker SSL cert is valid and that
ServerName matches the certificate Common Name
Finally, enterprise updates:
Andre Dietisheim <adietish> made a comment on jira JBIDE-14760
Moving this WATCHER to 4.1.x since the root issue in OpenShift Enterprise is fixed but not published/released yet. We keep watching it and will resolve it once we can test against a fixed instance.
Verify this on puddle:
After setting up OSE env, check the ServerName of broker and nodes:
[root@broker conf.d]# cat 000002_openshift_origin_broker_servername.conf |grep ServerName
# a consistent default ServerName broker.osevvv.com
[root@node conf.d]# cat 000001_openshift_origin_node_servername.conf|grep ServerName
# a consistent default ServerName node.osevvv.com
Both of them are correct.
Use oo-diagnostics to verify the broker SSL cert is valid, no error throw out.
[root@broker conf.d]# oo-diagnostics -v
INFO: loading list of installed packages
INFO: OpenShift broker installed.
INFO: running: test_broker_certificate
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.