Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Jenkins ver. 1.449
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
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
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)
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.
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
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.