Bug 975369 - TLS handshake alert: unrecognized_name
TLS handshake alert: unrecognized_name
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Rajat Chopra
libra bugs
: Reopened
Depends On:
Blocks: 1104765
  Show dependency treegraph
Reported: 2013-06-18 05:14 EDT by Andrew Bourgeois
Modified: 2016-08-01 11:07 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1104765 (view as bug list)
Last Closed: 2014-05-28 14:25:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Network capture of the issue (11.91 KB, application/octet-stream)
2013-06-18 05:14 EDT, Andrew Bourgeois
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker AGPUSH-324 Major Closed Java Clients running against OpenShift Push Server might hit SSL handshake exception 2018-04-22 22:56 EDT

  None (edit)
Description Andrew Bourgeois 2013-06-18 05:14:28 EDT
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:

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):
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 14:03:45 EDT
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 14:17:42 EDT
(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 14:18:40 EDT
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-09 21:45:49 EDT
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 10:18:17 EDT
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 18:46:09 EDT
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 19:10:30 EDT
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.

Comment 8 JBoss JIRA Server 2013-08-28 06:13:16 EDT
Karel Piwko <kpiwko@redhat.com> made a comment on jira AGPUSH-324

Linked bz issue. Still not fixed.
Comment 9 JBoss JIRA Server 2013-08-28 07:14:35 EDT
Matthias Wessendorf <matthias@wessendorf.net> made a comment on jira AGPUSH-324

yep, known issue and documented:


nothing the client lib really can do about it
Comment 10 JBoss JIRA Server 2013-08-28 09:33:00 EDT
Karel Piwko <kpiwko@redhat.com> 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 09:37:02 EDT
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 13:01:13 EDT
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 14:25:09 EDT
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 11:07:44 EDT
Matthias Wessendorf <matthias@wessendorf.net> updated the status of jira AGPUSH-324 to Closed

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