Articles

Fix Jenkins SSL Certificate Verification Failures (2026)

April 18, 2026 5 min read

Jenkins is failing to verify SSL certificates because the system’s trusted certificate store doesn’t contain the certificate authority (CA) that signed the Jenkins server’s certificate.

Common Causes and Fixes

1. Outdated CA Certificate Bundle on Jenkins Agent

  • Diagnosis: On the Jenkins agent machine, check the system’s CA certificate bundle. The location varies by OS:
    • Debian/Ubuntu: /etc/ssl/certs/ca-certificates.crt
    • RHEL/CentOS/Fedora: /etc/pki/tls/certs/ca-bundle.crt
    • macOS (using Homebrew OpenSSL): /usr/local/etc/openssl/cert.pem
    • Windows: Typically managed by the OS, but Java keystores (cacerts) are also common for Java applications. Check $JAVA_HOME/lib/security/cacerts.
    • Run openssl s_client -connect jenkins.example.com:8443 -showcerts < /dev/null 2>/dev/null | openssl x509 -text -noout | grep 'Issuer:' to see the issuer of the Jenkins certificate. Then, manually inspect your system’s CA bundle to see if that issuer (or its parent CA) is present.
  • Fix: Update the CA certificate bundle.
    • Debian/Ubuntu: sudo apt-get update && sudo apt-get install --reinstall ca-certificates
    • RHEL/CentOS/Fedora: sudo yum update ca-certificates or sudo dnf update ca-certificates
    • macOS (Homebrew): brew update && brew upgrade openssl
    • Windows (Java): If Jenkins runs as a Java application, you might need to import the CA certificate into the Java cacerts file. Use keytool -importcert -keystore $JAVA_HOME/lib/security/cacerts -alias myjenkinsCA -file /path/to/your/jenkins_ca.crt. The default password for cacerts is changeit.
  • Why it works: This ensures the agent’s operating system or Java runtime has the latest trusted root certificates, allowing it to validate the certificate chain presented by the Jenkins server.

2. Jenkins Agent Using a Custom or Self-Signed Certificate

  • Diagnosis: If the Jenkins server is using a certificate issued by an internal CA or a self-signed certificate, the agent’s default trust store won’t have it. Check the Jenkins server’s SSL configuration to identify the CA or certificate being used. You can often see this in the web browser when accessing Jenkins (click the padlock).
  • Fix: Distribute the Jenkins server’s CA certificate (or the self-signed certificate itself) to all Jenkins agents and import it into their trusted certificate stores.
    • Linux Agents: Copy the CA certificate (jenkins_ca.crt) to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates.
    • Windows Agents: Import the certificate into the "Trusted Root Certification Authorities" store via certmgr.msc.
    • Java Agents: Use keytool -importcert -keystore $JAVA_HOME/lib/security/cacerts -alias myjenkinsCA -file /path/to/jenkins_ca.crt on each agent.
  • Why it works: Explicitly trusting the specific CA or self-signed certificate used by Jenkins on the agent side bypasses the need for it to be in the system’s general trust store.

3. Network Interception (e.g., Proxy, Firewall, Antivirus)

  • Diagnosis: Some network devices or security software perform SSL inspection, presenting their own certificate in place of the original one. This "man-in-the-middle" certificate might not be trusted by the Jenkins agent. Check network diagrams and consult with network administrators. On the agent, try curl -v https://jenkins.example.com:8443. The output will show which certificate is actually being presented. If the issuer is different from what you expect (e.g., your company’s proxy CA), this is the issue.
  • Fix: Either configure the network device to exclude Jenkins traffic from SSL inspection or import the network device’s intermediate/root CA certificate into the Jenkins agent’s trust store (using methods described in Cause 2).
  • Why it works: By either removing the interception or trusting the certificate presented by the intercepting device, the agent can successfully complete the TLS handshake.

4. Incorrect JAVA_HOME or Keystore Configuration on Agent

  • Diagnosis: If Jenkins is running as a Java application on the agent (e.g., via agent.jar), it might be using a specific Java runtime and its own cacerts file, which could be outdated or misconfigured. Check the JAVA_HOME environment variable set for the Jenkins agent process. Verify the cacerts file at $JAVA_HOME/lib/security/cacerts contains the necessary CA.
  • Fix: Ensure the JAVA_HOME environment variable points to a Java installation with an up-to-date cacerts file, or update the cacerts file in the specific JAVA_HOME being used by the agent (using keytool as described in Cause 1).
  • Why it works: Jenkins, when running as a Java process, relies on the Java runtime’s trust store. Correcting this specific store allows Jenkins to validate the server’s certificate.

5. Time Skew Between Agent and Server

  • Diagnosis: SSL certificates have validity periods. If the clock on the Jenkins agent is significantly ahead of the server’s clock (or vice-versa), the certificate might appear expired or not yet valid, even if it’s technically within its valid range. Check the system time on both the Jenkins server and the agent. Use date on Linux/macOS or check the clock settings on Windows.
  • Fix: Synchronize the time on the Jenkins agent with a reliable NTP server. On Linux: sudo ntpdate pool.ntp.org or configure chronyd/ntpd. On Windows, ensure "Internet Time" synchronization is enabled.
  • Why it works: Accurate time synchronization ensures that the certificate’s validity period is evaluated correctly during the TLS handshake.

6. Corrupted Certificate Cache on Agent

  • Diagnosis: In rare cases, the operating system or application might cache a corrupted version of a certificate or its validation status.
  • Fix: Clear the relevant certificate cache.
    • Linux: For system-wide caches, sudo update-ca-certificates --fresh might help. For application-specific caches, consult the application’s documentation.
    • Windows: The certificate cache can sometimes be cleared by restarting the "Cryptographic Services" service (services.msc).
    • Browser: If the failure is seen in a browser accessing Jenkins, clearing the browser’s cache and cookies might resolve it.
  • Why it works: Forcing a re-fetch and re-validation of certificates, free from potentially corrupted cached data, allows for a correct verification.

The next error you’ll likely encounter after fixing SSL verification is a "Connection Refused" error if the Jenkins agent is unable to establish a network connection to the Jenkins master’s port (e.g., 8443).

Want structured learning?

Take the full Jenkins course →