Skip to main content

[SOLVED] How to Fix the TrustAnchors Parameter Must Be Non-Empty Error in Jenkins? - jenkins

Resolving the TrustAnchors Parameter Must Be Non-Empty Error in Jenkins: A Simple Guide

In this chapter, we will look at the “TrustAnchors parameter must be non-empty” error in Jenkins. This error usually happens because of issues with the Java Truststore setup. The Truststore is important for safe connections when Jenkins talks to outside services. We will share a simple guide to help us fix this issue. This will make sure our Jenkins works safely and reliably. We will talk about different ways to solve this problem. This includes updating the Java Truststore, adding missing certificates, and setting Jenkins to use the right Truststore settings.

Here are the solutions we will discuss:

  • Part 1 - Update Java Truststore: We will learn how to update the Java Truststore to add needed certificates.
  • Part 2 - Import Missing Certificates into Truststore: We will give step-by-step instructions on how to add any missing certificates into the Truststore.
  • Part 3 - Configure Jenkins to Use System Truststore: We will show how to set up Jenkins to use the system’s Truststore for managing certificates.
  • Part 4 - Check for Java Version Compatibility: We will check that our Java version works well with Jenkins to avoid TrustAnchors errors.
  • Part 5 - Set Up Jenkins with a Custom Truststore: We will guide us to set up a special Truststore just for Jenkins.
  • Part 6 - Validate Network Connectivity and Proxy Settings: We will give tips on checking network settings that might stop Jenkins from reaching outside services.
  • Frequently Asked Questions: We will answer common questions about the TrustAnchors parameter error.

By following this guide, we can fix the TrustAnchors parameter must be non-empty error in Jenkins. This will help us keep a safe and working environment for our CI/CD tasks.

Part 1 - Update Java Truststore

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we need to make sure that our Java Truststore has the right certificates. This is important because Jenkins uses the Truststore to keep HTTPS connections safe.

  1. Find your Java installation: We have to find where Java is installed. You can usually find it here:

    • For Windows: C:\Program Files\Java\jre<version>\lib\security\cacerts
    • For Linux/Mac: /usr/lib/jvm/java-<version>/lib/security/cacerts
  2. Backup your Truststore: Before we change anything, we should make a backup of the Truststore:

    cp cacerts cacerts.bak
  3. Update the Truststore: We will use the keytool command to update the Truststore. If we want to add a certificate, we need to run:

    keytool -importcert -file <path_to_certificate_file> -keystore <path_to_cacerts> -alias <alias_name>
    • Change <path_to_certificate_file> with where your certificate is.
    • Change <path_to_cacerts> with the path to your cacerts file.
    • Change <alias_name> with a name for your certificate.
  4. Default password: The default password for the Java Truststore is changeit. We will enter this when asked.

  5. Restart Jenkins: After we update the Truststore, we need to restart Jenkins. This will make the changes take effect.

By making sure our Java Truststore is updated, we can fix the TrustAnchors parameter must be non-empty error in Jenkins. If we still have problems, we can check Part 2 - Import Missing Certificates into Truststore for more help.

Part 2 - Import Missing Certificates into Truststore

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we might need to import missing certificates into the Java Truststore. We can do this using the keytool command from Java. Let’s follow these simple steps to import the certificates we need:

  1. Locate the Certificate: First, we need to get the missing certificate file. This file is usually in .crt or .pem format.

  2. Identify the Java Truststore Location: The Java Truststore is usually found here:

    • For Oracle Java: JAVA_HOME/lib/security/cacerts
    • For OpenJDK: /etc/ssl/certs/java/cacerts
  3. Import the Certificate: Next, we use the keytool command to import the certificate into the Truststore. We should replace the placeholders with our actual paths and alias.

    keytool -importcert -file /path/to/your/certificate.crt -keystore $JAVA_HOME/lib/security/cacerts -alias your_alias_name
    • We need to enter the Truststore password. The default password is changeit.
  4. Verify the Import: After we import the certificate, we can check if it was added by listing what is in the Truststore:

    keytool -list -keystore $JAVA_HOME/lib/security/cacerts -alias your_alias_name
  5. Restart Jenkins: Finally, after we import the missing certificates into the Truststore, we should restart our Jenkins instance. This helps Jenkins see the updates.

For more details on related settings, we can check Part 1 - Update Java Truststore or Part 3 - Configure Jenkins to Use System Truststore.

Part 3 - Configure Jenkins to Use System Truststore

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we can set up Jenkins to use the system truststore. This helps Jenkins to get the important certificates that are stored in the Java truststore. Here are the steps we can follow to set up Jenkins correctly:

  1. Locate the Java Truststore: First, we need to find where the Java truststore (often named cacerts) is located. It is usually in the JRE or JDK folder:

    • For JRE: <JAVA_HOME>/lib/security/cacerts
    • For JDK: <JAVA_HOME>/lib/security/cacerts
  2. Configure Jenkins to Use the Truststore: Next, we have to set the JAVA_OPTS environment variable to point to the truststore. We can change the Jenkins configuration file (like jenkins.xml for Windows or /etc/default/jenkins for Linux) to add this line:

    JAVA_OPTS="-Djavax.net.ssl.trustStore=<path_to_cacerts> -Djavax.net.ssl.trustStorePassword=changeit"

    We should replace <path_to_cacerts> with the real path to our cacerts file.

  3. Restart Jenkins: After we make these changes, we need to restart Jenkins so it can use the new settings.

  4. Verify the Configuration: We can check if Jenkins is using the right truststore by looking at the Jenkins logs. We should check for any SSL connection attempts and make sure there are no trust errors.

For more help with the “TrustAnchors parameter must be non-empty” error, we can look at Part 1 - Update Java Truststore and Part 2 - Import Missing Certificates into Truststore.

Part 4 - Check for Java Version Compatibility

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we need to check if our Java version works with Jenkins. Let’s follow these steps to check our Java version:

  1. Check Installed Java Version
    We can run this command in our terminal or command prompt to see our Java version:

    java -version

    We should have a supported version of Java. Jenkins usually works good with Java 8, 11, and 17.

  2. Update Java if Necessary
    If our Java version is old or does not work, we should download the latest supported version from the official Java website or use our package manager:

    • For Ubuntu/Debian:

      sudo apt update
      sudo apt install openjdk-11-jdk
    • For CentOS/RHEL:

      sudo yum install java-11-openjdk-devel
  3. Set JAVA_HOME Environment Variable
    We must set the JAVA_HOME variable to point to the correct Java installation. We can add or change this line in our .bashrc, .bash_profile, or .profile:

    export JAVA_HOME=/path/to/your/java

    We need to replace /path/to/your/java with our actual Java path. For example, it can be /usr/lib/jvm/java-11-openjdk-amd64.

  4. Restart Jenkins
    After we update Java or the JAVA_HOME variable, we need to restart Jenkins to apply the changes. We can do this with the command:

    sudo systemctl restart jenkins
  5. Verify Jenkins Compatibility
    We should check the Jenkins documentation for the version we are using. This helps us make sure our Java version is compatible.

By checking our Java version and making sure it works with Jenkins, we can solve the “TrustAnchors parameter must be non-empty” error. This helps us keep a stable Jenkins environment. For more help, we can look at related sections like Update Java Truststore and Import Missing Certificates into Truststore.

Part 5 - Set Up Jenkins with a Custom Truststore

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we can set up a custom truststore. This truststore will hold the necessary certificates. Let’s follow these steps:

  1. Create a Custom Truststore: We use the Java keytool command to make a new truststore and add the needed certificates.

    keytool -genkey -alias mykey -keyalg RSA -keystore customTruststore.jks -storepass changeit

    Change mykey to a name that describes your key. Change customTruststore.jks to the name you want for your truststore file.

  2. Import Certificates: Next, we add any missing certificates to the custom truststore.

    keytool -import -alias mycert -file /path/to/certificate.crt -keystore customTruststore.jks -storepass changeit

    Make sure to replace /path/to/certificate.crt with the real path to your certificate file.

  3. Configure Jenkins to Use the Custom Truststore: We need to change Jenkins startup settings so it points to our custom truststore. We can do this by adding these options to the Jenkins setup:

    For Linux:

    JAVA_OPTS="-Djavax.net.ssl.trustStore=/path/to/customTruststore.jks -Djavax.net.ssl.trustStorePassword=changeit"

    For Windows:

    set JAVA_OPTS="-Djavax.net.ssl.trustStore=C:\path\to\customTruststore.jks -Djavax.net.ssl.trustStorePassword=changeit"

    Remember to replace /path/to/customTruststore.jks or C:\path\to\customTruststore.jks with the correct path to your custom truststore.

  4. Restart Jenkins: After we set up the truststore, we need to restart Jenkins to apply the changes.

  5. Verify Configuration: We should check the Jenkins logs. This will help us see if there are any SSL errors and if Jenkins recognizes the custom truststore.

If we need more help, we can look at the section on Importing Missing Certificates into Truststore. This can guide us if we have issues during the truststore setup.

Part 6 - Validate Network Connectivity and Proxy Settings

To fix the “TrustAnchors parameter must be non-empty” error in Jenkins, we need to check our network connection and proxy settings. If there are problems with the network or the proxy, we may have trouble making secure connections.

  1. Check Network Connectivity:

    • First, we check if the Jenkins server can connect to outside services.

    • We can use ping or curl commands to test the connection.

      ping example.com
      curl -I https://example.com
  2. Proxy Configuration:

    • If our Jenkins is behind a proxy, we must set the proxy settings in the Jenkins global settings.

    • We go to Manage Jenkins then Manage Plugins and click on the Advanced tab to set the HTTP Proxy settings.

    • We can also add proxy details in the Jenkins startup options:

      JAVA_OPTS="-Dhttp.proxyHost=your.proxy.host -Dhttp.proxyPort=8080 -Dhttps.proxyHost=your.proxy.host -Dhttps.proxyPort=8080"
  3. Environment Variables:

    • We may need to set these environment variables:

      export http_proxy=http://your.proxy.host:8080
      export https_proxy=https://your.proxy.host:8080
  4. Testing Proxy:

    • We can check if the proxy works by accessing a known HTTPS site from the Jenkins server:

      curl -x http://your.proxy.host:8080 -I https://www.google.com
  5. Firewall Settings:

    • We should make sure that firewall rules let outbound connections to needed ports, like 443 for HTTPS.
  6. Logs and Errors:

    • We need to look at Jenkins logs for any error messages about network or proxy issues. This can help us understand more.

By checking our network connection and setting up the proxy correctly, we can avoid the “TrustAnchors parameter must be non-empty” error in Jenkins. This will help Jenkins run smoothly. For more help, we can check the Jenkins documentation for network settings and configurations.

Frequently Asked Questions

1. What causes the “TrustAnchors parameter must be non-empty” error in Jenkins?

We see the “TrustAnchors parameter must be non-empty” error in Jenkins when the Java environment can’t find valid certificates in the truststore. This usually means the truststore is empty or missing the right root certificates needed to make SSL connections. To fix this problem, check our guide on how to solve the TrustAnchors parameter must be non-empty error in Jenkins.

2. How do I update the Java truststore in Jenkins?

To update the Java truststore in Jenkins, we need to find the cacerts file in the Java installation and add the needed certificates. We can do this with the Java keytool command. For detailed steps, look at Part 1 of our article on fixing the TrustAnchors parameter must be non-empty error in Jenkins.

3. What is the role of a custom truststore in Jenkins?

A custom truststore in Jenkins helps us manage our own trusted certificates. It is separate from the default Java truststore. This is very helpful when we work with internal servers or APIs that use self-signed certificates. For a complete setup guide, see Part 5 of our article on solving the TrustAnchors parameter must be non-empty error in Jenkins.

4. How can I check for Java version compatibility in Jenkins?

To check Java version compatibility in Jenkins, we should make sure the Java version we use is supported by the Jenkins version. We can look at the Jenkins documentation or the release notes for compatibility details. For more information, check Part 4 of our article on how to fix the TrustAnchors parameter must be non-empty error in Jenkins.

5. What steps should I take to validate network connectivity and proxy settings in Jenkins?

To check network connectivity and proxy settings in Jenkins, we start by looking at the Jenkins system logs for any connection errors. We must ensure the proxy settings are set up correctly in Jenkins’ global settings. For a full guide, refer to Part 6 of our article on fixing the TrustAnchors parameter must be non-empty error in Jenkins.

Comments