Diagnosing SSL or Connectivity errors for Runtime Fabric Installs and Application Traffic

DIAGNOSTIC APPROACH:
Start by testing outbound connectivity from the RTF nodes themselves:

rtfctl test outbound-network --namespace <rtf_namespace>

This exercises connectivity from inside the cluster to the required MuleSoft endpoints and is the first thing to run when validation errors appear.
Because the affected endpoints require mTLS or standard TLS, any interception or alteration of the certificate chain by a firewall or proxy will break the handshake and is visible in the certificate issuer returned.

To confirm whether certificate replacement is occurring, run the following from within the cluster environment for each endpoint in question:

openssl s_client -connect transport-layer.prod.cloudhub.io:443 -showcerts | grep -E "s:|i:"
openssl s_client -connect us1.ingest.mulesoft.com:443 -showcerts | grep -E "s:|i:"

These two are the most common examples but replace the hostnames as needed in your particular scenario.

Look at the "s:" (subject) and "i:" (issuer) lines in the output. If the issuer is the organization's own internal CA rather than the expected public MuleSoft/DigiCert CA, that endpoint is being intercepted by corporate SSL inspection. Repeat this check against any other endpoint showing a certificate-related failure, since interception is often endpoint-specific rather than blanket.
For a running application already installed, TRACE-level logging can also be enabled on the relevant client/policy scope through the Application Manager API to see exactly which outbound call is failing and against which endpoint.

Check each relevant endpoint individually and do not assume a single bypass rule covers all of them: endpoints seen affected in real cases include the container registry, exchange-files.anypoint.mulesoft.com, us1.ingest.mulesoft.com, and internal ingestor/router endpoints. A bypass list that covers some but not all required endpoints will leave the application partially broken (for example, image pulls succeed but policy downloads still fail).
For a running application already installed, you can also enable TRACE-level logging on the relevant client/policy scope through the Application Manager API to see exactly which outbound call is failing and against which endpoint.

RESOLUTION:
- For the transport-layer.prod.cloudhub.io mTLS false positive: no action needed. This is expected validator behavior against an mTLS-only endpoint, not a defect.
- For us1.ingest.mulesoft.com or any endpoint where the openssl check shows a replaced certificate: work with the network/security team to add that specific endpoint to the SSL inspection bypass list. Expect this to be iterative: after each bypass update, re-run rtfctl test outbound-network and re-check certificate issuers, since a round of bypass changes may miss an endpoint that only becomes visible once an earlier blocking error clears.
- If an application also shows repeated OOMKilled restarts alongside SSL or policy-download errors, treat that as a separate, compounding issue: a memory-driven crash loop will keep re-triggering failed startup sequences (including policy downloads) even after the SSL inspection issue itself is fixed. Rule this out or fix it independently.