Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-1720

RHEL7 Java 1.8.0_121 update causes Java class errors for CA server; Java downgrade/re-upgrade resolves



    • Bug
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • SERVER 2.7.2
    • None
    • Puppet Server
    • 2
    • WC 2017-02-08
    • Needs Assessment


      This morning, our Puppet CA server, a RHEL7 box, updated its java packages from:

      openjdk version "1.8.0_111"
      OpenJDK Runtime Environment (build 1.8.0_111-b15)
      OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)


      openjdk version "1.8.0_121"
      OpenJDK Runtime Environment (build 1.8.0_121-b13)
      OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

      This was a security update only. It should not have changed any Java functionality. But this update completely broke our Puppet CA Server.

      Specifically, when Puppet Server is running using openjdk version 1.8.0_121, new Puppet clients cannot submit certificates for signing. Instead, they return this error:

      Error: Could not request certificate: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A

      On the Puppet CA Server, the following is logged:

      2017-02-01 11:36:41,728 WARN  [qtp2094712335-181] [o.e.j.u.t.QueuedThreadPool] 
      java.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SupportedEllipticCurvesExtension
              at sun.security.ssl.HelloExtensions.<init>(HelloExtensions.java:82)
              at sun.security.ssl.HandshakeMessage$ClientHello.<init>(HandshakeMessage.java:245)
              at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:220)
              at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
              at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)
              at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)
              at java.security.AccessController.doPrivileged(Native Method)
              at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)
              at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:612)
              at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:239)
              at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
              at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
              at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
              at java.lang.Thread.run(Thread.java:745)
      2017-02-01 11:36:41,729 WARN  [qtp2094712335-181] [o.e.j.u.t.QueuedThreadPool] Unexpected thread death: org.eclipse.jetty.util.thread.QueuedThreadPool$3@1b278e22 in qtp2094712335{STARTED,8<=8<=200,i=5,q=0}

      If we stop the Puppet CA Server, downgrade the OpenJDK packages back to 1.8.0_111, and then restart the Puppet CA Server, all functionality is restored, and the Puppet CA Server works correctly, without logging the above messages.

      If it matters: we use autosigning for our hosts, and we have a separate Puppet CA Server.

      I suspect that one (or both) of the following is true:

      • The OpenJDK 1.8.0_121 update is broken (either by OpenJDK, or by Red Hat).
      • The Puppet CA Server code is broken, but no version of OpenJDK before 1.8.0_121 managed to step on the brokenness.

      Is this Puppet's fault? Or do we need to go yell at Red Hat and/or the OpenJDK folks?


        Issue Links



              Unassigned Unassigned
              ralston James Ralston
              0 Vote for this issue
              12 Start watching this issue



                Zendesk Support