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/.

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

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.