Jenkins Remoting Agent - Expired Certificate

[Dunnigan, Terrence J]

Has anyone else encountered this?

 

We’re running Jenkins LTS 1.554.3 and Java Server SDK 7u72 on a Windows 2008 Server, and Java 7u72 on the slave workstations. When we restarted our server yesterday none of our slaves connected via DCOM. They never made it past the first (Connecting to …) or second (Checking for Java) step.

 

At the same time, I’m now seeing Java security warnings on the slaves when running the Jenkins Remoting Agent. The code signing certificate expired just a few days ago (7/18). Could this be related to my DCOM errors?

 

 

Terry

[Kohsuke Kawaguchi]

Yes, my code signing certificate expired.

Up until about 2 years ago, I was signing these bits without including the timestamp. That has the unfortunate side effect of invalidating the signature when my certificate expires, which happens sooner or later.

Since then I have modified the signing process to include the timestamp, so that the signed & release bits will continue to pass the signature test even when a certificate expires. That happened about 2 years ago. You are running a fairly old version, so I suspect you ae running an affected version. That said, 1.554.3 has slave jar 2.36, which should have the timestamp. Are you sure your slave.jar is up-to-date against the master?  Can you look at the slave manifest to see the version number?

I recommend you ugprade Jenkins altogether, but to get unblocked quickly, just download the latest slave.jar from here and use it as the slave.jar.

[Dunnigan, Terrence J]

Thank you! I appreciate the prompt response and assistance. I can confirm I am using slave jar 2.36 when I get the security warning I described below.

 

Terry

 

Terry

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cd816250-564c-4b33-8937-27db667005dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Prashant Sawant]

Hi There , 

I am facing same issue ... my slave,jar and remoting.jar are both on 2.52 , still it's giving me security issue

can you please advice

Thanks 

Prashant

[Prashant Sawant]

Jenkins master is hosted on Windows server 2012 and I am trying installing slave on separate Windows Server 2012

[Daniel Beck]

On 08.03.2016, at 19:21, Prashant Sawant <pras....@gmail.com> wrote:

> I am facing same issue ... my slave,jar and remoting.jar are both on 2.52 , still it's giving me security issue

Time to update Jenkins. Even the no longer supported 1.625.x LTS release line is on 2.53.2.

[Prashant Sawant]

Jenkins is on 1.624 ... 

[Prashant Sawant]

Hi 

Thanks I have updated the slave and remoting to 2.53.3 and jenkins to 1.652 , the error is gone  

but now i am facing issue another issue , when i am trying to launch slave node from slave machine it throws me below exception

 I am login as admin  on slave machine , I am able to access dashboard from slave that means port is not an issue , does it need port 22 to open , can you please help 

 java.net.MalformedURLException: unknown protocol: socket

at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)

at java.net.URI.toURL(Unknown Source)

at com.sun.deploy.net.proxy.DeployProxySelector.connectFailed(Unknown Source)

at java.net.SocksSocketImpl.connect(Unknown Source)

at java.net.Socket.connect(Unknown Source)

at java.net.Socket.connect(Unknown Source)

at sun.net.NetworkClient.doConnect(Unknown Source)

at sun.net.www.http.HttpClient.openServer(Unknown Source)

at sun.net.www.http.HttpClient.openServer(Unknown Source)

at sun.net.www.http.HttpClient.<init>(Unknown Source)

at sun.net.www.http.HttpClient.New(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)

at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)

at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)

at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)

at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)

at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)

at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)

at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)

at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)

at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

 

On Tuesday, March 8, 2016 at 8:03:03 PM UTC, Daniel Beck wrote: