AnsweredAssumed Answered

Test for invalid Apache SNI/Wildcard/Multi-domain configuration

Question asked by Wessel van Norel on Jul 23, 2014
Latest reply on Aug 11, 2014 by Gurken Papst

We have run a few times into an issue with invalid apache configurations in combination with Java 7+. If the Apache server supports SNI (which will become more popular now Windows XP is finally end of life) or if the server uses wildcard / multi-domain certificates, and you have not added the correct ServerName / ServerAlias for the host being accessed, Apache will send a SSL warning and will return the content of the default virtual host. Most clients just ignore this SSL warning, but Java clients don't. At least not when SNI support is enabled (which is default from Java 7+)[1]. In the Java application you will get:

 

javax.net.ssl.SSLProtocolException: handshake alert:  unrecognized_name

 

Many people call it a bug in Java because it's a warning, not an error. But in the end the RFC 3546[2] says that it may be fatal. And in the eyes of the Java maintainers it's not a bug, since it's RFC compliant. The only situation I'm not totally convinced that it's not a bug is when the website owner has a wildcard certificate and he wants to serve SSL pages for just any subdomain, since adding a *.example.com ServerAlias in that case doesn't help. But I think in most situations where people get this exception, it's really because of a misconfiguration.

If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal).

 

My main concern at this time is that the "default advice" given to people using Java 7+ and this error is: disable SNI support. Sure, that works, until the application they are using needs to be able to connect to a site using SNI and to a misconfigured website. And as stated before, I think SNI will become more and more an acceptable solution to host multiple SSL websites from the same ip address, and so this wil become a bigger issue.

 

There is also a real workaround possible[3], but better would be if the Apache admin would "just" configure his host correctly (just add the correct ServerName/ServerAlias(ses) to the specific host). But since all SSL test sites I tried so far don't check for this, it takes a while before the Apache admin knows(/acknowledges) that he/she has done something wrong.

 

A way to test if the server is doing things properly is the following openssl command:

 

SERVER=BROKEN_HOST_ALIAS_HERE; echo -e "HEAD / HTTP/1.0\r\nHost: $SERVER\r\n\r\n" | openssl s_client -servername $SERVER -connect $SERVER:443 -state


On an incorrectly configured server this will generate reason(1112), where the first 1 stands for warning and the 112 stands for unknown name.

38306:error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112):/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_clnt.c:602:

 

I found an example server that is misconfigured on one of the many bug reports this issue has[4]: fbo-test.symplicity.com. The SSL test is A-[5] and no (real) failures, but you cannot use it with Java 7 & SNI enabled.

 

Is it possible to add a test for this in the SSL Labs test-suite so Apache admins are warned about this type of misconfiguration? Or am I barking at the wrong tree and should I try to convince the Java maintainers to see this as a bug and get them fix it?

 

Wessel

 

[1] SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0 - Stack Overflow

[2] RFC 3546 - Transport Layer Security (TLS) Extensions

[3] Workaround for Java bailing out on TLS warning due to SNI · 8f2362e · Lekensteyn/OWASP-WebScarab · GitHub

[4] [#JDK-8025572] Web Service error 'Message Send Failed: Handshake Alert: unrecognized_name - Java Bug System

[5] Qualys SSL Labs - Projects / SSL Server Test / fbo-test.symplicity.com

Outcomes