Docker部署的Jenkins无法安装插件：已配置SSL证书仍报PKIX路径构建失败求助

Let’s walk through the most likely issues and fixes for your SSL handshake error—even though you’ve added the certificates, there are a few common pitfalls that might be tripping you up.

1. Check if Your Custom cacerts is Accessible & Configured Correctly #

First, confirm that Jenkins can actually read your custom cacerts file and that you’re providing the right password (if you changed it from the default changeit):

• SSH into your container:

  docker exec -it <your-jenkins-container-name/id> bash
  

• Verify the file exists and has correct permissions:

  ls -l /var/jenkins_home/keystore/cacerts
  

  It should be readable by root (since you’re running Jenkins as root).
• Ensure the certificates are properly stored and the password works:

  keytool -list -v -keystore /var/jenkins_home/keystore/cacerts -storepass <your-keystore-password>
  

  Double-check that all four Jenkins domains have valid entries, and look at the Certificate chain section to confirm you imported the full chain (not just the server certificate—missing intermediate CAs is a top cause of PKIX errors).

2. Verify JAVA_OPTS Are Actually Being Applied #

Sometimes environment variables in docker-compose don’t propagate as expected. Let’s confirm Jenkins is using your custom truststore:

• Inside the container, run:

  ps aux | grep java
  

  Look for the -Djavax.net.ssl.trustStore=/var/jenkins_home/keystore/cacerts flag in the output. If it’s missing, check your docker-compose file for typos (e.g., extra spaces, incorrect variable names).
• Critical Note: If you changed the cacerts password from the default changeit, you need to add this to your JAVA_OPTS:

  -Djavax.net.ssl.trustStorePassword=<your-password>
  

  Without this, the JVM will try the default password and fail to access the truststore.

3. Test SSL Connectivity Directly in the Container #

Let’s rule out network or certificate chain issues by testing the update site with curl:

• Inside the container, run:

  curl -v https://updates.jenkins.io/update-center.json
  

  If this throws an SSL error, your certificate import is incomplete. To fix this, re-import the full certificate chain for each domain:

  # Example for updates.jenkins.io
  openssl s_client -connect updates.jenkins.io:443 -showcerts < /dev/null | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > jenkins-updates.crt
  keytool -import -trustcacerts -alias updates.jenkins.io -file jenkins-updates.crt -keystore /var/jenkins_home/keystore/cacerts
  

  Repeat this for the other Jenkins domains.

4. Fallback: Replace the JDK’s Default cacerts #

If your custom truststore setup isn’t working, try replacing the JDK’s default cacerts file entirely:

• Find the JDK’s security directory in the container:

  echo $JAVA_HOME/lib/security/cacerts
  

  For the lts-jdk11 image, this is usually /usr/local/openjdk-11/lib/security/cacerts.
• Copy your custom cacerts over the default one:

  cp /var/jenkins_home/keystore/cacerts $JAVA_HOME/lib/security/cacerts
  

• Restart your Jenkins container:

  docker-compose restart jenkins
  

Common Mistakes to Double-Check #

• You imported only the server certificate, not the intermediate CA certificates required for full chain validation.
• The cacerts file permissions are too restrictive (even as root, if the file is chmod 600 it might cause issues—use chmod 644 for read access).
• There’s a typo in the JAVA_OPTS path (e.g., missing a directory, misspelling keystore).

内容的提问来源于stack exchange，提问作者Somesh Garje