ISSUE:
When uploading a client certificate (CA-signed or self-signed) to a Private Space TLS context truststore, the upload is rejected with the error:
"Invalid CA Path file uploaded. Certificate Chain validation failed."
This can occur even when the certificate chain is correctly formatted, PEM-encoded, and includes all required intermediate CA certificates in the correct order.
CAUSE:
This matches an Engineering-acknowledged Known Issue affecting CloudHub 2.0 Private Space TLS contexts (see reference below). At the time of writing, no permanent fix has shipped and the Known Issue page does not publish a workaround.
The following workaround has resolved this exact error across multiple support cases:
- Open the affected TLS context and select Edit. Do NOT delete and recreate the TLS context.
- In the edit window, re-enter ALL configuration values, even fields that have not changed: server certificate, private key, CA path, and the Truststore.
- Select Update TLS Context to apply the changes.
Re-entering the complete set of values during an in-place edit is the key step. This allows certificate chain validation to complete successfully where a partial edit does not.
If the error persists after trying this workaround, confirm the following about the uploaded file:
- It is PEM encoded (begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----).
- It includes any intermediate CA certificate(s) needed to complete the chain.
- The certificates are concatenated in order: intermediate CA(s) first, then the root CA.
ADDITIONAL NOTES:
This is a workaround, not a permanent fix. Check the Known Issue page periodically for a status update, as the underlying platform behavior is still being tracked by the CloudHub 2.0 Private Spaces engineering team.
REFERENCES:
Known Issue: https://help.salesforce.com/s/issue?id=a02Ka00000eNx4xIAC
Configuring Endpoints and Paths for Apps Deployed to a Private Space: https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space#configure-endpoint-path005390239

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.