[JENKINS-25333] Jenkins 1.586 not starting up using Java8

[jenkins-infra-bot]

Using Java8, Jenkins doesn't start with the following message:

SCHWERWIEGEND: Container startup failed
java.io.IOException: Failed to start a listener: winstone.HttpsConnectorFactory
   at winstone.Launcher.spawnListener(Launcher.java:209)
   at winstone.Launcher.<init>(Launcher.java:149)
   at winstone.Launcher.main(Launcher.java:354)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:483)
   at Main._main(Main.java:293)
   at Main.main(Main.java:98)
Caused by: java.lang.NoClassDefFoundError: sun/security/x509/CertAndKeyGen
   at winstone.HttpsConnectorFactory.start(HttpsConnectorFactory.java:101)
   at winstone.Launcher.spawnListener(Launcher.java:207)
   ... 8 more
Caused by: java.lang.ClassNotFoundException: sun.security.x509.CertAndKeyGen
   at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
   ... 10 more

After switching back to Oracle Java 7, it works without problems.

---

Originally reported by maxzilla, imported from: Jenkins 1.586 not starting up using Java8

• assignee: jglick
• status: Resolved
• priority: Critical
• component(s): core
• label(s): 2.32.2-fixed, java8, winstone
• resolution: Fixed
• resolved: 2016-12-27T13:03:39+00:00
• votes: 11
• watchers: 14
• imported: 2025-11-24

Raw content of original issue

Using Java8, Jenkins doesn't start with the following message:


SCHWERWIEGEND: Container startup failed
java.io.IOException: Failed to start a listener: winstone.HttpsConnectorFactory
   at winstone.Launcher.spawnListener(Launcher.java:209)
   at winstone.Launcher.<init>(Launcher.java:149)
   at winstone.Launcher.main(Launcher.java:354)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:483)
   at Main._main(Main.java:293)
   at Main.main(Main.java:98)
Caused by: java.lang.NoClassDefFoundError: sun/security/x509/CertAndKeyGen
   at winstone.HttpsConnectorFactory.start(HttpsConnectorFactory.java:101)
   at winstone.Launcher.spawnListener(Launcher.java:207)
   ... 8 more
Caused by: java.lang.ClassNotFoundException: sun.security.x509.CertAndKeyGen
   at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
   ... 10 more


After switching back to Oracle Java 7, it works without problems.

• environment: Debian 7 Wheezy x86-64, Oracle Java 8, Jenkins 1.586

[jenkins-infra-bot]

• Remote links associated with this issue:

  • winstone PR 23
  • PR 29
  • core PR 2673
  • CloudBees Internal OSS-153

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Other workarounds would be to offload SSL to a reverse proxy and access Jenkins through that (so jetty-winstone only serves HTTP), or use another container.
  

Other workarounds would be to offload SSL to a reverse proxy and access Jenkins through that (so jetty-winstone only serves HTTP), or use another container.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Or sorry, perhaps this is not a regression after all—did this work in older versions of Jenkins? It looks like this code to manage certificates never worked in Java 8. Does it work if you specify httpsKeyStore?
  
  See comments in: jenkinsci/winstone@bb47b5b
  

Or sorry, perhaps this is not a regression after all—did this work in older versions of Jenkins? It looks like this code to manage certificates never worked in Java 8. Does it work if you specify httpsKeyStore?

See comments in: jenkinsci/winstone@bb47b5b

[jenkins-infra-bot]

kohsuke:

• Original comment link
• Raw content of original comment:

  I'm pretty sure we can generate self-signed certificate by using the JCA API directly without relying on sun.* packages. Let me see...
  

I'm pretty sure we can generate self-signed certificate by using the JCA API directly without relying on sun.* packages. Let me see...

[jenkins-infra-bot]

smithj4:

• Original comment link
• Raw content of original comment:

  This is now also an issue for Java 7 on RedHat Enterprise 5, 6 & 7, since a few weeks ago, a java-1.7.0-openjdk security update was released for all RHEL versions that updated it to u111 and also moves the CertAndKeyGen class from /sun/security/x509/CertAndKeyGen.class to /sun/security/tools/keytool/CertAndKeyGen.class:
  
  https://rhn.redhat.com/errata/RHSA-2016-1504.html
  
  It looks like this comes directly from the upstream openjdk, from their Mercurial source code repo:
  
  http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/tip/src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
  
  I also found a github pull request that was opened a few months ago to address this issue:
  
  [JENKINS-25333] Self Signed certificates with JDK8 winstone#23
  

This is now also an issue for Java 7 on RedHat Enterprise 5, 6 & 7, since a few weeks ago, a java-1.7.0-openjdk security update was released for all RHEL versions that updated it to u111 and also moves the CertAndKeyGen class from /sun/security/x509/CertAndKeyGen.class to /sun/security/tools/keytool/CertAndKeyGen.class:

https://rhn.redhat.com/errata/RHSA-2016-1504.html

It looks like this comes directly from the upstream openjdk, from their Mercurial source code repo:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/tip/src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java

I also found a github pull request that was opened a few months ago to address this issue:

jenkinsci/winstone#23

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  What are the circumstances for this to happen? Reading the code indicates it's only when relying on ad-hoc cert generation in winstone-jetty, i.e. neither a keystore nor a prepared SSL cert.
  

What are the circumstances for this to happen? Reading the code indicates it's only when relying on ad-hoc cert generation in winstone-jetty, i.e. neither a keystore nor a prepared SSL cert.

[jenkins-infra-bot]

smithj4:

• Original comment link
• Raw content of original comment:

  I am using the RedHat Jemkins rpms, and have this config setting: JENKINS_HTTPS_PORT="8443", which adds this argument to the java command line in the initscript: --httpsPort=8443. But I think this is irrelevant, since the failure comes from the import:
  
  https://github.com/jenkinsci/winstone/blob/master/src/java/winstone/HttpsConnectorFactory.java#L18
  
  since the class path was moved. So even if I used my own keystore for the cert & key, importing sun.security.x509.CertAndKeyGen will still fail.
  

I am using the RedHat Jemkins rpms, and have this config setting: JENKINS_HTTPS_PORT="8443", which adds this argument to the java command line in the initscript: --httpsPort=8443. But I think this is irrelevant, since the failure comes from the import:

https://github.com/jenkinsci/winstone/blob/master/src/java/winstone/HttpsConnectorFactory.java#L18

since the class path was moved. So even if I used my own keystore for the cert & key, importing sun.security.x509.CertAndKeyGen will still fail.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  smithj4 Yes, so you're relying on ad-hoc cert functionality. Just create a cert and reference that and you should be fine.
  
  Imports don't really matter here, otherwise the stack trace in the issue description wouldn't have called start() and reached line 101.
  

smithj4 Yes, so you're relying on ad-hoc cert functionality. Just create a cert and reference that and you should be fine.

Imports don't really matter here, otherwise the stack trace in the issue description wouldn't have called start() and reached line 101.

[jenkins-infra-bot]

schristou:

• Original comment link
• Raw content of original comment:

  danielbeck Maybe it's best to remove this functionality from Winstone. My PR was just to give us some time before removing it completely. The fix I provided won't work with JDK 9, so this might give us a few months(years?) to suggest to avoid using the built-in cert generation and use a valid one before everyone starts using JDK 9 heavily. I could also provide an error on startup suggesting everyone switch to using an outside certificate instead.
  

danielbeck Maybe it's best to remove this functionality from Winstone. My PR was just to give us some time before removing it completely. The fix I provided won't work with JDK 9, so this might give us a few months(years?) to suggest to avoid using the built-in cert generation and use a valid one before everyone starts using JDK 9 heavily. I could also provide an error on startup suggesting everyone switch to using an outside certificate instead.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  schristou Would be viable, provided it doesn't break things for anyone currently using it successfully. E.g. print a deprecation warning for them and otherwise work, and print a useful error message otherwise. Just removing the parameter and getting something like "This argument doesn't exist" has the potential to break users' instances.
  

schristou Would be viable, provided it doesn't break things for anyone currently using it successfully. E.g. print a deprecation warning for them and otherwise work, and print a useful error message otherwise. Just removing the parameter and getting something like "This argument doesn't exist" has the potential to break users' instances.

[jenkins-infra-bot]

wilson_ds_net:

• Original comment link
• Raw content of original comment:

  It would be very useful to get this feature of Jenkins working again.  Our setup uses Active Directory user authentication and with Jenkins using http on the default port 8080, the paswords are potentially compromised if someone starts sniffing traffic on the server.
  
  I've been trying to get the -httpsport option working with no success and happened to stumble across this ticket which explained things.  Now I'm trying to get a signed certificate to install, but I have to say SSL/TLS is not something I've had to deal with much so this is a little confusing (learning about CSR, CRT, JKS, KEY, etc.).  If this could be better explained, or just plain fixed as documented, I'm sure a lot of people would be very grateful.
  

It would be very useful to get this feature of Jenkins working again. Our setup uses Active Directory user authentication and with Jenkins using http on the default port 8080, the paswords are potentially compromised if someone starts sniffing traffic on the server.

I've been trying to get the -httpsport option working with no success and happened to stumble across this ticket which explained things. Now I'm trying to get a signed certificate to install, but I have to say SSL/TLS is not something I've had to deal with much so this is a little confusing (learning about CSR, CRT, JKS, KEY, etc.). If this could be better explained, or just plain fixed as documented, I'm sure a lot of people would be very grateful.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  If this could be better explained
  
  The documentation (and usage instructions) says:
  
  --httpsPrivateKey    this switch with --httpsCertificate can be used to run HTTPS with OpenSSL secret key file and the corresponding certificate file
  
  These files are the output of pretty much every OpenSSL "how to create a self-signed certificate" tutorial on the web.
  
  I don't think we need to write another one.
  

If this could be better explained

The documentation (and usage instructions) says:

--httpsPrivateKey this switch with --httpsCertificate can be used to run HTTPS with OpenSSL secret key file and the corresponding certificate file

These files are the output of pretty much every OpenSSL "how to create a self-signed certificate" tutorial on the web.

I don't think we need to write another one.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  I think in the world of letsencrypt.org there is no reason to keep this functionality undeprecated.
  

I think in the world of letsencrypt.org there is no reason to keep this functionality undeprecated.

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   .gitignore
   Jenkinsfile
   pom.xml
   src/java/winstone/HttpsConnectorFactory.java
   src/java/winstone/LocalStrings.properties
  http://jenkins-ci.org/commit/winstone/14b69f14db22af3b4f5b1078eb63290a98082eae
  Log:
    Merge pull request #29 from jglick/self-signed-JENKINS-25333
  
  JENKINS-25333 Avoid hard dependency on non-Java-Platform APIs
  
  
  Compare: jenkinsci/winstone@79bc5ac...14b69f1
  
  

Code changed in jenkins
User: Jesse Glick
Path:
.gitignore
Jenkinsfile
pom.xml
src/java/winstone/HttpsConnectorFactory.java
src/java/winstone/LocalStrings.properties
http://jenkins-ci.org/commit/winstone/14b69f14db22af3b4f5b1078eb63290a98082eae
Log:
Merge pull request #29 from jglick/self-signed-JENKINS-25333

JENKINS-25333 Avoid hard dependency on non-Java-Platform APIs

Compare: jenkinsci/winstone@79bc5ac...14b69f1

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   war/pom.xml
  http://jenkins-ci.org/commit/jenkins/4f814c0a9f8e72384046015975f201f4f693abaf
  Log:
    [FIXED JENKINS-25333] Update to Winstone 3.2. (#2673)
  
  
  

Code changed in jenkins
User: Jesse Glick
Path:
war/pom.xml
http://jenkins-ci.org/commit/jenkins/4f814c0a9f8e72384046015975f201f4f693abaf
Log:
[FIXED JENKINS-25333] Update to Winstone 3.2. (#2673)