Bug 975369

Summary: TLS handshake alert: unrecognized_name
Product: OpenShift Online Reporter: Andrew Bourgeois <andrew.bourgeois>
Component: ContainersAssignee: Rajat Chopra <rchopra>
Status: CLOSED UPSTREAM QA Contact: libra bugs <libra-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.xCC: adietish, andrew.bourgeois, dmcphers, erich, jialiu, kpiwko, lmeyer, mfisher, nduong
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1104765 (view as bug list) Environment:
Last Closed: 2014-05-28 18:25:09 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1104765    
Attachments:
Description Flags
Network capture of the issue none

Description Andrew Bourgeois 2013-06-18 09:14:28 UTC
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).

Comment 1 Luke Meyer 2013-06-26 18:03:45 UTC
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.

Comment 2 Nam Duong 2013-06-26 18:17:42 UTC
(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?

Comment 3 Luke Meyer 2013-06-26 18:18:40 UTC
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).

Comment 4 Rob Millner 2013-07-10 01:45:49 UTC
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?

Comment 5 Andrew Bourgeois 2013-07-10 14:18:17 UTC
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.

Comment 6 Rob Millner 2013-07-30 22:46:09 UTC
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.

Comment 7 Rob Millner 2013-08-19 23:10:30 UTC
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

Comment 8 JBoss JIRA Server 2013-08-28 10:13:16 UTC
Karel Piwko <kpiwko> made a comment on jira AGPUSH-324

Linked bz issue. Still not fixed.

Comment 9 JBoss JIRA Server 2013-08-28 11:14:35 UTC
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

Comment 10 JBoss JIRA Server 2013-08-28 13:33:00 UTC
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.

Comment 11 Eric Rich 2014-05-16 13:37:02 UTC
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

Comment 12 Eric Rich 2014-05-19 17:01:13 UTC
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.

Comment 13 Rajat Chopra 2014-05-28 18:25:09 UTC
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.

Comment 14 JBoss JIRA Server 2016-08-01 15:07:44 UTC
Matthias Wessendorf <matthias> updated the status of jira AGPUSH-324 to Closed