"PKIX path building failed" errors after RA Agent upgrade
Article ID: 107756
Updated On:
Products
Issue/Introduction
After upgrading the CA Release Automation Agent, deployment jobs now return PKIX errors for actions that run against https URLs. For example, our F5-List All Pool Members action is returning: Error occurred during action execution: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
Environment
CA Release Automation 6.6, 6.7, 6.8
Cause
The cacerts keystore is replaced during the upgrade.
Resolution
There are two solutions depending on whether or not you have a backup of the cacerts keystore file from before the upgrade.
Solution 1:
If you do not have a backup of the cacerts keystore file from before the upgrade then you will need to obtain a copy of the certificate for that https server and then import it into the Agent's jre/lib/securiuty/cacerts keystore. Steps for this can be found here: javax.net.ssl.SSLHandshakeException PKIX path building failed
Solution 2:
If you do have a backup of the cacerts keystore file from before the upgrade then you can list the content of the old keystore, review it for which certs you imported, export the custom certificate from the old keystore and then import it into the new keystore. An example of these steps are:
NOTE:
Default password for cacerts keystore is changeit
Step1:
Open a command prompt and run: cd <path to backup jre/lib/security folder>
*Then run: keytool -list -keystore .\cacerts > certsPriorToUpgrade.out
Step2:
Review the certificates listed in the certsPriorToUpgrade.out and identify the aliases of any custom certificates.
Examples:
teamcitycertificate
sonatype artifact repo
artifactory artifact repo
TIP:
Looking through the list of certificates in the cacerts to highlight custom certificates can be a little overwhelming if you're not sure what's custom and what isn't. This tip might help:
Look for certificates that seem like they are default certificates (like something for verisign). Then look at the date listed for it. This is the date that the certificate was added. That specific date will often be used as the date when the other default certificates were imported. So if you see a certificate that you're unsure with that date then can, probably, skip it. If you're not sure then you can run the following command to get more details to see if it is for one of your systems: keytool -list -v -alias "name of alias in question - quotation marks only necessary if the alias has spaces" -keystore .\cacerts
Step3:
Export each custom certificates from the backed up cacerts file:
example 1: keytool -exportcert -alias teamcitycertificate -file teamcitycertificate.jks -keystore C:\Path\To\Backup\cacerts
**example 2: keytool -exportcert -alias "sonatype artifact repo" -file "sonatype artifact repo.jks" -keystore C:\Path\To\Backup\cacerts
Step4:
Import the certificate, exported in step3, to the new cacerts keystore:
example 1: keytool -importcert -file teamcitycertificate.jks -alias teamcitycertificate -keystore D:\Path\To\NolioAgent\jre\lib\security\cacerts
**example 2: keytool -importcert -file "sonatype artifact repo.jks" -alias "sonatype artifact repo" -keystore D:\Path\To\NolioAgent\jre\lib\security\cacerts
Comments:
* If you get an error about the keytool command not being a valid/recognized command then you can provide the full path to <AgentInstallDir>/jre/bin/keytool
** Take note of the quotation marks surrounding the alias and filename. This is because both of them have spaces. You only need to use quotation marks surrounding values if they have spaces in their values.
Additional Information
Feedback
