SSL renegotiation fails against JDK 1.6.0_20, but works with JDK1.6.0_18. An exception similar to the following is written to the system.log file:
[#|2010-05-25T13:57:34.512-0700|WARNING|glassfish3.0.1|com.sun.grizzly. \ config.GrizzlyServiceListener|_ThreadID=24;_ThreadName=Thread-1; \ |processorTask.exceptionSSLcert javax.net.ssl.SSLHandshakeException: \ renegotiation is not allowed |
This is a known issue caused by the disabling of SSL renegotiation in JDK 6u19 and above. Previously, GlassFish Server was able to perform SSL renegotiation for client certificates through the default HTTPS port (8181). However, a security vulnerability with SSL renegotiation surfaced, and SSL renegotiation was disabled in JDK 6u19.
The security vulnerability was in the TLS protocol (TLS 1.0 or later and SSLv3), and it was discovered that this vulnerability may allow an unauthenticated, remote attacker to conduct man-in-the-middle (MITM) type of attacks, where plain text may be injected as a prefix in a user's TLS session. More details about this vulnerability are available at http://extendedsubset.com/?p=8.
An interim fix was made in JDK 6u19 that disables TLS/SSL renegotiation in the Java Secure Sockets Extension (JSSE) by default. This stops the MITM attack, but applications that require the TLS/SSL renegotiation will not work. The remaining and real fix for this will be done in JDK 6u22. For more information about this, see http://blogs.sun.com/security/entry/vulnerability_in_tls_protocol_during.
JDK 6u19 provides a new system property, called sun.security.ssl.allowUnsafeRenegotiation, that enables TLS/SSL renegotiation. For more information, see http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html. Setting this property to true in GlassFish Server GlassFish enables the renegotiation. However, it also makes GlassFish Server once again vulnerable to MITM attack.