1

In troubleshooting an issue with my Tomcat servlet I decided to enable network debugging by editing /var/apache-tomcat-8.5.5/bin/setenv.sh and changing the line export JAVA_OPTS="-Xms512m -Xmx1536m -XX:MaxPermSize=256m" to export JAVA_OPTS="-Xms512m -Xmx1536m -XX:MaxPermSize=256m -Djavax.net.debug=all". As soon as I saved the file and restarted Tomcat (via catalina.sh start/stop) I found that I could no longer connect to the Tomcat manager app (https://10.9.9.236:8443/manager/html/) via HTTPS. Chrome says:

"This site can't be reached" (ERR_CONNECTION_CLOSED)

I reproduced this behavior after completely stopping and un-deploying my webapp. (Only the default Tomcat manager apps are installed now.) So I know it's only that one Java option that is causing HTTPS to fail.

Why would enabling debugging break HTTPS?

Here is a possible clue from the catalina.out log file:

https-jsse-nio-8443-exec-4, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
https-jsse-nio-8443-exec-4, SEND TLSv1.2 ALERT:  fatal, description = internal_error
https-jsse-nio-8443-exec-4, WRITE: TLSv1.2 Alert, length = 2
28-Sep-2016 14:01:00.576 SEVERE [https-jsse-nio-8443-exec-4] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun 
 java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
    at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1429)
    at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
    at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
    at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
    at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
    at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:449)
    at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:227)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1387)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
    at sun.security.util.ECUtil.getECParameters(ECUtil.java:100)
    at sun.security.util.ECUtil.getECParameterSpec(ECUtil.java:149)
    at sun.security.ssl.JsseJce.getECParameterSpec(JsseJce.java:385)
    at sun.security.ssl.SupportedEllipticCurvesExtension.toString(SupportedEllipticCurvesExtension.java:127)
    at sun.security.ssl.HelloExtensions.print(HelloExtensions.java:150)
    at sun.security.ssl.HandshakeMessage$ClientHello.print(HandshakeMessage.java:323)
    at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:340)
    at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
    at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
    at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
    at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:397)
    at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:457)
    ... 7 more
Caused by: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
    at java.security.Security.getImpl(Security.java:695)
    at java.security.AlgorithmParameters.getInstance(AlgorithmParameters.java:146)
    at sun.security.util.ECUtil.getECParameters(ECUtil.java:98)
    ... 21 more

When I wipe the logs and revert back to the default JAVA_OPTS, the exception does not occur.

Environment:

CentOS Linux release 7.2.1511 (Core)
uname -r: 3.10.0-327.10.1.el7.x86_64

Using CATALINA_BASE:   /var/apache-tomcat-8.5.5
Using CATALINA_HOME:   /var/apache-tomcat-8.5.5
Using CATALINA_TMPDIR: /var/apache-tomcat-8.5.5/temp
Using JRE_HOME:        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre
Using CLASSPATH:       /var/apache-tomcat-8.5.5/bin/bootstrap.jar:/var/apache-tomcat-8.5.5/bin/tomcat-juli.jar
Using CATALINA_PID:    /var/apache-tomcat-8.5.5/tomcat.pid

I should add that even when HTTPS access to the servlet is broken, I can still access it via HTTP, e.g. http://10.9.9.236:8080/manager/html/.

Jordan Rieger
  • 388
  • 1
  • 6
  • 18

1 Answers1

2

The problem is OpenJDK 8 dos not support elliptic curve ciphers when attempting to debug SSL connection (Eg javax.net.debug=all).

Try update java-1.8.0-openjdk packages to fix this bug.

See more: java-1.8.0-openjdk bug fix update

Federico Sierra
  • 3,499
  • 1
  • 18
  • 24
  • Thanks, this fixed it for me. For others who aren't familiar with Tomcat administration, note that after `yum update java-1.8.0-openjdk`, the old JRE directory under `/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-1.b13.el7_2.x86_64/jre` was renamed or moved to reflect the new version. So I had to update the `JRE_HOME=` line in my Tomcat's `/bin/setenv.sh` file. Then it worked. – Jordan Rieger Sep 29 '16 at 20:36