TLS/mTLS Certificate Failure Isolation and Outbound Connectivity Resilience

[cpapendorf]

We have experienced recurring incidents during certificate updates in Chorus where a certificate configuration issue, typically relating to certificate/keystore password misalignment or password compatibility (for example, special characters), results in a significantly broader platform impact than expected.

To date, we have observed this behaviour primarily during mTLS certificate updates. When an mTLS certificate or its associated keystore is incorrectly configured, the impact does not appear to be limited to the integrations explicitly requiring client-certificate authentication. Instead, all SSL/TLS-based outbound integrations from Chorus become unavailable, resulting in a complete loss of outbound API connectivity rather than an isolated failure of the affected mTLS interfaces.

This creates a significant operational risk during certificate introduction, renewal, replacement and configuration changes, as an issue affecting a single certificate or keystore can potentially become a common point of failure for otherwise unrelated integrations.

While our incidents have predominantly involved mTLS, we would like the investigation to extend beyond mTLS and consider the handling of all TLS certificates, keystores and trust stores used by Chorus. We want to establish whether similar failure behaviour could occur when any TLS-related certificate or configuration is expired, unavailable, invalid, incorrectly configured, or protected by an incorrect or incompatible password.

Could you please investigate:

• Why a failure associated with an mTLS certificate or keystore can affect outbound HTTPS integrations that do not require mTLS.
• Whether Chorus uses any shared SSL/TLS context, certificate store, keystore, trust store or initialization process that creates this common failure dependency.
• Whether equivalent behaviour could occur with other TLS certificates or certificate stores, even where mTLS is not involved.
• The failure behaviour when individual certificates are expired, invalid, unavailable, incorrectly configured, or have an incorrect/incompatible keystore password.
• Whether certificate and keystore validation failures can be handled in a manner that isolates the failure to the integration or function that actually depends upon that certificate.

Ideally, we would like the platform architecture and certificate handling to ensure that:

• mTLS-specific client certificates and keystores are isolated from general outbound TLS/HTTPS communication.
• Individual TLS certificates, keystores and trust stores are isolated from unrelated integrations wherever technically appropriate.
• A failure affecting one certificate, keystore or TLS configuration impacts only the integrations that depend upon it.
• Standard HTTPS integrations that do not require a client certificate continue to operate if an mTLS client certificate is expired, unavailable or incorrectly configured.
• Unrelated TLS integrations continue to operate where a different certificate or certificate store has a configuration problem.
• Invalid certificate or keystore configuration is detected and reported with sufficiently specific diagnostics to identify the affected certificate/store and dependent integration, rather than resulting in a wider loss of outbound connectivity.

Given that Chorus 26.1 includes a specific correction for outbound mutual TLS whereby the platform reads the mTLS system configuration before invoking connector APIs, we would also appreciate confirmation of whether this change affects, or is intended to improve, the failure/isolation behaviour described above.
Blue Prism Chorus 26.1 Release Notes documents this change under (AWD-85176) Outbound mutual TLS.