Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: SERVER 2.7.2
-
Fix Version/s: None
-
Component/s: Puppet Server
-
Labels:
-
Template:customfield_10700 173260
-
Story Points:2
-
Sprint:WC 2017-02-08
-
QA Risk Assessment:Needs Assessment
Description
This morning, our Puppet CA server, a RHEL7 box, updated its java packages from:
java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64
|
java-1.8.0-openjdk-headless-1.8.0.111-2.b15.el7_3.x86_64
|
|
|
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)
|
To:
java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64
|
java-1.8.0-openjdk-headless1.8.0.121-0.b13.el7_3.x86_64
|
|
|
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?
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
- links to