4

I've got a problem with Jenkins.

I'm using the current LTS build (2.60.2) on a master/slave environment (Master: Debian no workers, Slave1: Windows 8 workers, Slave2: Debian 8 workers).

The Jenkins Master uses SSL to secure communications and is configured to work fine. The other servers (SonarQube, Nexus) use custom SSL certificates to secure communication with those systems.

Now, I have the problem. My build pipelines using Gradle have to use an JDK with my root certificate in the cacerts to communicate correctly with the SSL secured systems. The only solutions for this I could find by google, were to Install the JDKs and afterwards to add the certificate to the truststore. This has to be redone after every JDK update.

This solution works properly but is not the wanted behaviour for keeping the JDKs up to date. Is there any possibility to append the root certificate automatically to the internal (build) JDK of Jenkins or is it necessary to add it manually on every server manually?

E_net4
  • 27,810
  • 13
  • 101
  • 139
The_Gentleman
  • 1,045
  • 2
  • 10
  • 18

1 Answers1

3

you could configure the jvm process to use a custom truststore/keystore instead of relying on the default jdk file.

to be clear: i'm talking about pointing to another truststore/keystore file (that you can have wherever you want and won't be overwritten on jdk upgrade).

some info here (for example javax.net.ssl.truststore property).

albert_nil
  • 1,648
  • 7
  • 9
  • 1
    We did try this. Works quite well as long as there are no Processes that spawn independent java processes in jenkins pipeline. The new calls have to get the information aswell. Then it works. – The_Gentleman Aug 30 '17 at 09:29
  • 1
    For us, we switched to releasing the JDKs with approval of QS for our company. It's the better solution for our scenario. So your way works, but the internal analysis resulted in another way with us... – The_Gentleman Aug 30 '17 at 09:30