Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-12629

Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      We have Jenkins setup to use only HTTPS port with arguments "--httpPort=-1 --httpsPort=8080" that starts server with self signed certificate.

      Using web browser is all ok but when connecting with jenkins-cli.jar it fails due to hostname not being the same as server actual hostname.

      Steps to reproduce (using bash):

      JENKINS_HOST=foo.bar.host
      JENKINS_PORT=8080
      JENKINS_URL=https://${JENKINS_HOST}:${JENKINS_PORT}
      
      # Get HTTPS certificate for java
      openssl s_client -connect ${JENKINS_HOST}:${JENKINS_PORT} </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${JENKINS_HOST}.cer
      keytool -import -noprompt -trustcacerts -alias ${JENKINS_HOST} -file ${JENKINS_HOST}.cer -keystore myKeystore -storepass 123456
      keytool -list -v -keystore myKeystore -storepass 123456
      
      # Get jenkins-cli
      wget --no-check-certificate ${JENKINS_URL}/jnlpJars/jenkins-cli.jar
      
      # Test access
      alias jcli="java -Djavax.net.ssl.trustStore=myKeystore -Djavax.net.ssl.trustStorePassword=123456 -jar jenkins-cli.jar -s ${JENKINS_URL,,}"
      jcli help
      

      Error displayed:

      Exception in thread "main" java.io.IOException: Failed to connect to https://foo.bar.host:8080/
              at hudson.cli.CLI.getCliTcpPort(CLI.java:211)
              at hudson.cli.CLI.<init>(CLI.java:115)
              at hudson.cli.CLI._main(CLI.java:375)
              at hudson.cli.CLI.main(CLI.java:314)
      Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name mat
      ching localhost found
              at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
              at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
              at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
              at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
              at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
              at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
              at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
              at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
              at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
              at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
              at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
              at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
              at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
              at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
              at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
              at hudson.cli.CLI.getCliTcpPort(CLI.java:209)
              ... 3 more
      Caused by: java.security.cert.CertificateException: No name matching localhost found
              at sun.security.util.HostnameChecker.matchDNS(Unknown Source)
              at sun.security.util.HostnameChecker.match(Unknown Source)
              at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(Unknown Source)
              at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
              ... 15 more
      

      I think the root cause is related to how the self-certificate is being generated that should be using the machine actual hostname in the CN part instead of "Test site":

      Owner: CN=Test site, OU=Unknown, O=Unknown, C=Unknown
      Issuer: CN=Test site, OU=Unknown, O=Unknown, C=Unknown
      

        Attachments

          Activity

          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          cli/src/main/java/hudson/cli/NoCheckTrustManager.java
          http://jenkins-ci.org/commit/jenkins/867a35523c2f6cf7a88e1ddb11c471652c7df5a9
          Log:
          [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate.

          • NoCheckTrustManager needed to implement X509TrustManager not just plain TrustManager

          (cherry picked from commit 0ab79882978292f3751be8e0acf5ae7edb0751f1)

          Compare: https://github.com/jenkinsci/jenkins/compare/de78db8d6ba0...867a35523c2f

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: cli/src/main/java/hudson/cli/NoCheckTrustManager.java http://jenkins-ci.org/commit/jenkins/867a35523c2f6cf7a88e1ddb11c471652c7df5a9 Log: [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate. NoCheckTrustManager needed to implement X509TrustManager not just plain TrustManager (cherry picked from commit 0ab79882978292f3751be8e0acf5ae7edb0751f1) Compare: https://github.com/jenkinsci/jenkins/compare/de78db8d6ba0...867a35523c2f
          Hide
          danielbeck Daniel Beck added a comment -

          Does not seem to be in 1.532.x, so should probably be backported to 1.532.2, as it's effectively a regression from 1.509.4.

          Show
          danielbeck Daniel Beck added a comment - Does not seem to be in 1.532.x, so should probably be backported to 1.532.2, as it's effectively a regression from 1.509.4.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          cli/src/main/java/hudson/cli/NoCheckTrustManager.java
          http://jenkins-ci.org/commit/jenkins/fb71d62ae163d39e289d9cb11b57abd9aabbef4d
          Log:
          [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate.

          • NoCheckTrustManager needed to implement X509TrustManager not just plain TrustManager

          (cherry picked from commit 0ab79882978292f3751be8e0acf5ae7edb0751f1)

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: cli/src/main/java/hudson/cli/NoCheckTrustManager.java http://jenkins-ci.org/commit/jenkins/fb71d62ae163d39e289d9cb11b57abd9aabbef4d Log: [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate. NoCheckTrustManager needed to implement X509TrustManager not just plain TrustManager (cherry picked from commit 0ab79882978292f3751be8e0acf5ae7edb0751f1)
          Hide
          dogfood dogfood added a comment -

          Integrated in jenkins_main_trunk #2893
          [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate. (Revision 0ab79882978292f3751be8e0acf5ae7edb0751f1)

          Result = UNSTABLE
          Stephen Connolly : 0ab79882978292f3751be8e0acf5ae7edb0751f1
          Files :

          • cli/src/main/java/hudson/cli/NoCheckTrustManager.java
          Show
          dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2893 [FIXED JENKINS-12629] Using jenkins-cli connecting to HTTPS port fails due to hostname mismatch in certificate. (Revision 0ab79882978292f3751be8e0acf5ae7edb0751f1) Result = UNSTABLE Stephen Connolly : 0ab79882978292f3751be8e0acf5ae7edb0751f1 Files : cli/src/main/java/hudson/cli/NoCheckTrustManager.java
          Hide
          stephenconnolly Stephen Connolly added a comment -

          Adding as an lts-candidate as the latest fix (0ab79882978292f3751be8e0acf5ae7edb0751f1) is just a widening of the implemented interface of NoCheckTrustManager from implements TrustManager to implements X509TrustManager so is zero risk and fixes the bug.

          Show
          stephenconnolly Stephen Connolly added a comment - Adding as an lts-candidate as the latest fix (0ab79882978292f3751be8e0acf5ae7edb0751f1) is just a widening of the implemented interface of NoCheckTrustManager from implements TrustManager to implements X509TrustManager so is zero risk and fixes the bug.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            josesa Jose Sa
            Votes:
            3 Vote for this issue
            Watchers:
            13 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: