If you have enabled SSL on Jenkins, you probably get the following error when you start to have your slave start to communicate with the Jenkins master.
Exception in thread "main" java.io.IOException: Failed to validate a server certificate. If you are using a self-signed certificate, you can use the -noCertificateCheck option to bypass this check.
It means that the java process does not trust the SSL certificate and the application is not going to continue because some weird guy could be eavesdropping the communication between the slave and the Jenkins master. Let’s see how we can have the slave side trust the SSL certificate.
First of all, let’s download the publicly exposed SSL certificate using Chrome browser.
Open Jenkins master using Chrome browser. Click the key icon and select Certificate (Valid). Save the .cer file in Details tab. I have saved the file to my desktop.
- Open your command line as an administrator on Windows.
- Execute the following command to save the SSL certificate to trust.
openssl s_client -showcerts -connect jks.westus.cloudapp.azure.com:443 <
| openssl x509 -outform DER > azure-jenkins.com.cer
- Execute the command to trust the certificate.
keytool -trustcacerts -keystore "%JAVA_HOME%\lib\security\cacerts" -storepass changeit -alias jks.westus.cloudapp.azure -import -file "C:\Users\amaterasu48\Desktop\azure-jenkins.cer"
- The path C:\Users\amaterasu48\Desktop\azure-jenkins.cer should be replaced with wherever you have the .cer file saved on your slave machine.
- Once the keytool command is successful, the Java process on the slave machine trusts the SSL cert on Jenkins master and it’s ready to communicate with the Jenkins master.
My batch file for the slave to communicate with the Jenkins master looks like this.
java -jar agent.jar -jnlpUrl https://jks.westus.cloudapp.azure.com/computer/win-bld01/slave-agent.jnlp -secret e54b3aasdfasdfasdfasdfsdfasdfasdfasdfsadfasdfbea3e889 -workDir "C:\Users\amaterasu48\workspaces"
You can get the command by adding a node on Jenkins master and saving it. I am using JNLP to communicate with the Jenkins master.
If you save the command and execute it, you will successfully start the communication between the slave machine and Jenkins master. Part of the log is in Japanese because I use a Windows machine in Japanese but you get the idea. You run the command to communicate with the Jenkins master successfully now.
Agent address: jks.westus.cloudapp.azure.com Agent port: 5378 Identity: 97:d8:c1:6f:31:e9:4e:07:58:bd:82:32:db:1b:7f:56 5月 20, 2019 11:50:44 午後 hudson.remoting.jnlp.Main$CuiListener status 情報: Handshaking 5月 20, 2019 11:50:44 午後 hudson.remoting.jnlp.Main$CuiListener status 情報: Connecting to jks.westus.cloudapp.azure.com:5378 5月 20, 2019 11:50:44 午後 hudson.remoting.jnlp.Main$CuiListener status 情報: Trying protocol: JNLP4-connect 5月 20, 2019 11:50:45 午後 hudson.remoting.jnlp.Main$CuiListener status 情報: Remote identity confirmed: 97:d8:c1:6f:31:e9:4e:07:58:bd:82:32:db:1b:7f:56 5月 20, 2019 11:50:45 午後 hudson.remoting.jnlp.Main$CuiListener status 情報: Connected 5月 20, 2019 11:50:48 午後 org.jenkinsci.remoting.util.AnonymousClassWarnings warn 警告: Attempt to (de-)serialize anonymous class org.jenkinsci.plugins.envinject.EnvInjectComputerListener$2; see: https://j enkins.io/redirect/serialization-of-anonymous-classes/ WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to field java.lang.reflect.Field.modifiers WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release
To recap, the slave Java process must trust the Jenkins master’s SSL certificate to establish secure SSL connection.