Loading
Salesforce Enforces New Security Requirements in Summer 2026Read More

CloudHub 2.0 Let's Encrypt Certificate Chain Update: Resolving PKIX Path Building Errors

Publish Date: Jul 13, 2026
Description

CloudHub 2.0 has started rolling out an updated Let's Encrypt certificate chain hierarchy for its default *.[privatespace-unique-id].[region].cloudhub.io endpoints. Let's Encrypt has introduced a new intermediate and root structure to this chain.

 

The Problem: When the Mule application acting as a client with the older version of the Runtime version or the patch version connects to these endpoints, it will experience this issue. This happens because older truststores do not yet recognize the new hierarchy. When a client attempts an HTTPS connection to an updated CloudHub 2.0 endpoint, it cannot build the complete certificate chain, resulting in the PKIX error.

 

Certificate Chain Comparison

 

Old Certificate Chain

New Certificate Chain

Depth 0 (Leaf)

*.[privatespace-unique-id].[region].cloudhub.io

*.[privatespace-unique-id].[region].cloudhub.io

Depth 1 (Intermediate)

Let's Encrypt R12

Let's Encrypt YR1

Depth 2 (Root)

ISRG Root X1

Root YR

Depth 3 (Root)

N/A

ISRG Root X1

 

Verification via OpenSSL:

Old Chain Output:

depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
depth=1 C=US, O=Let's Encrypt, CN=R12
depth=0 CN=*.lxxxdj.aus-s1.cloudhub.io

New Chain Output:

depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X1
depth=2 C=US, O=ISRG, CN=Root YR
depth=1 C=US, O=Let's Encrypt, CN=YR1
depth=0 CN=*.mxxx32.irl-e1.cloudhub.io

Impacted Environments

  • Target Endpoints: CloudHub 2.0 applications utilizing the default Let's Encrypt certificate endpoint (app-name.[privatespace-unique-id].[region].cloudhub.io).

  • Mule Clients: Older Mule Runtime versions or patch versions with default truststores that do not yet include the Root YR certificate.

  • Third-Party Clients: Older external systems, API clients, or partner systems that previously imported the ISRG Root X1 certificate into their truststore manually, but have not updated it to include the new Root YR (and potentially the YR1 intermediate).

Resolution

Resolution

To resolve this issue, you must ensure that the client making the HTTPS request trusts the new certificate chain. Choose the option that applies to your architecture:

Option 1: Update the Mule Runtime (Recommended for Mule Clients)

Update your client applications to the latest Mule Runtime patch release. Newer releases include the updated Let's Encrypt root certificates (Root YR) in their default Java truststore (cacerts), allowing the runtime to natively validate the new chain.

 

Option 2: Implement a Custom Truststore (For Unpatched Mule Clients)

If you cannot immediately upgrade your Mule Runtime, you can explicitly trust the new certificates by configuring a custom TLS Context in your HTTP Requester.

  1. Download the missing Let's Encrypt certificates (Root YR and ISRG Root X1) 

  2. In your Mule application, configure the downloaded certificates as truststore in HTTP Requester.

  3. Deploy the updated application.

 

Option 3: Update Third-Party Client Truststores (For External Clients)

If external or third-party systems are failing to connect to your CloudHub 2.0 APIs, their system administrators must update their respective truststores.

  1. Add the New Root: The external client must import the Root YR certificate into their truststore. Relying solely on the older ISRG Root X1 will no longer work for the new chain.

  2. Add the Intermediate (If Required): Depending on how strict the third-party client's SSL implementation is at building chains, they may also need to explicitly download and import the new intermediate certificate CN=YR1 into their truststore to successfully complete the handshake.

 

Please raise an Mulesoft Support case if you required any assistance regarding this issue.

Knowledge Article Number

005388920

 
Loading
Salesforce Help | Article