Created attachment 762440 [details] Network capture of the issue Description of problem: The server sends a TLS "Alert (Level: Warning, Description: Unrecognized name)" to the browser when it tries to load an applet from the OpenShift servers. In Java 7 the applet won't load as it'll send a "Alert(Level: Fatal, Description: unexpected message)" back to the server. In Java 6 the applet will load BUT the TLS session will be in a somewhat corrupt state because of this (I'm not the designer of the Applet, the Belgian government is, but it tells me that it detected it). Version-Release number of selected component (if applicable): How reproducible: Easy Steps to Reproduce: 1. Open up your preferred packet sniffer (tcpdump, Wireshark, ...) 2. Navigate to (the Applet itself is signed by the Belgian government so you can trust it to run): https://dev-demmelbe.rhcloud.com/eid.jsp 3. You'll see the Alert in your network traffic Actual results: "Alert (Level: Warning, Description: Unrecognized name)" as a reply to the TLSv1 Client Hello request. Expected results: No Alert Additional info: 1) http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0 ^ for those that are using Apache it appears that it's a common issue where you forgot to configure the correct VirtualHost. 2) Please find attached a network capture that contains the relevant packets. It can be opened with Wireshark. 3) The same WAR works fine on my local environment where I don't use Apache (so I don't get the alert).
OS Enterprise ran into this as bug 970805 in the context of JBoss developer tools connecting to broker REST API - sounds like the same issue applies for Java 7 accessing apps over HTTPS as well. If it's the same issue, modifying ServerName in the main httpd config should resolve it.
(In reply to Luke Meyer from comment #1) > OS Enterprise ran into this as bug 970805 in the context of JBoss developer > tools connecting to broker REST API - sounds like the same issue applies for > Java 7 accessing apps over HTTPS as well. If it's the same issue, modifying > ServerName in the main httpd config should resolve it. Is this something Operations can do on OpenShift Online prod?
oo-diagnostics check test_broker_certificate tests that this problem doesn't arise on the broker; it should probably be expanded to test for it on nodes as well (and still work correctly when the hostname is non-resolvable as I've seen in Online devenvs).
We support SNI for applications through their own aliases and certificates. rhc alias add .... rhc update-cert ... Recommended short term workaround is to either turn off SNI in the java client code or use an application alias and SSL cert. OpenShift's non-SNI SSL is handled through the default virtual host, and proxying is managed by mod_rewrite due to the limitations we ran into with per-application virtual hosts. The Online environment uses a wildcard certificate for *.rhcloud.com that validates properly when SNI is not specified. Andrew, are either of those options viable for a short-term workaround for your application?
Disabling SNI in the applet I'm using isn't an option, it'll detect it and refuse to continue (I'm not the developer so...). I can try the update-cert workaround in about 2 weeks but as you keep talking about "short-term" I can only assume that it's going to be fixed in the long-term? I'm currently only using Openshift to see if it's a viable platform for the needs of the company I work for, so I can wait a while.
The underlying issue is that we use mod_rewrite instead of Apache Virtual Hosts to proxy to applications. Apache becomes very unwieldy with thousands of virtual hosts so we switched to mod_rewrite based proxying with databases of application endpoints. Applications that have their own alias and SSL certificates do get a properly configured virtual host and the client name verifies properly. Hence the workaround. The bug actually affects any application, but most clients seem to ignore the warning. Will conduct more research to see what our options are but I'm not confident this is fixable any time soon.
On further exploration, there doesn't appear to be a mechanism which allows the mod_rewrite based Apache front-end to handle SNI on the primary application address (name-domain.rhcloud.com). SNI is handled properly with aliases that supply their own SSL certificates. Created a new feature request to allow OpenShift to use either the mod_rewrite router for environments that require high density and Virtual Hosts for environments that dont. Unfortunately, Online requires high density and is stuck with mod_rewrite until we find a replacement web server that handles Online's other requirements better than Apache. https://trello.com/c/zw4iNj3g/245-frontendhttpserver-plugin-module-for-apache-virtual-hosts
Karel Piwko <kpiwko> made a comment on jira AGPUSH-324 Linked bz issue. Still not fixed.
Matthias Wessendorf <matthias> made a comment on jira AGPUSH-324 yep, known issue and documented: https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/README.md nothing the client lib really can do about it
Karel Piwko <kpiwko> made a comment on jira AGPUSH-324 Let's keep the issue open until they fix this in upstream. Then we can mark it as resolved.
https://access.redhat.com/site/solutions/49082 can be used to reproduce this issue with default gears. Also disabling SNI does not seem to work as shown by the following command. $ --> java -Djavax.net.debug=ssl,handshake -Djsee.enableSNIExtension=false JavaHttpsClient https://app-namespace.rhcloud.com/ 1
Also tried setting -Djsee.enableSNIExtension=false as part of the Server process, with rhc env add JAVA_OPTS_EXT="-Djsee.enableSNIExtension=false" --app <app> however after a restart the same test's above fail.
Currently SNI works on a separate port (using haproxy). Vhosts are implemented only for aliases. And mod_rewrite for the rest. To get around the problem we need a router that will heed to SNI on regular 443 port and handle it with or without a separate alias for the app. Also by handling SNI we mean that an application should have the option of not terminating the ssl at node/router, but at the gear endpoint. An haproxy15 based router has been tested for the purpose. This bug will get fixed whenever this upstream feature (router for openshift) makes ground.
Matthias Wessendorf <matthias> updated the status of jira AGPUSH-324 to Closed