Deprecation of TLS 1.0 and 1.1 General FAQ for MuleSoft

In an effort to ensure the highest security standards and help protect your data, on October 7, 2025, with the release of the MuleSoft 4.10 Edge version, MuleSoft will deprecate support for Transport Layer Security (TLS) versions 1.1 and earlier. This applies to both inbound and outbound connections to Anypoint Platform across all deployment models.

All existing TLS 1.0/1.1 inbound connections will be blocked on October 31, 2026 across all Mule runtime versions in CloudHub 1.0 and 2.0 deployments. This enforcement will not be applicable for Hybrid Deployments and Runtime Fabric.

 Sections covered in this article. 

• Key Dates
• General FAQs
• Testing which TLS version is used
• Cloudhub 1.0 FAQs
• Cloudhub 2.0 FAQs

Key Dates:

General FAQ

How can I check if a Mule application is using TLS 1.0 or 1.1?

See the section below, Testing which TLS version is used.

How can I check if a non-mule 3rd party or customer application is using TLS 1.0 or 1.1?

Follow guidance for the specific technology in use. The methods described in the section below, Testing which TLS version is used, help but it is the customer’s responsibility to determine the best method for their environment. MuleSoft does not provide support for third-party applications or tools.

Do these TLS changes apply to all environments or just production?

This applies to all environments at the same time. There is currently no option to enable TLS 1.0/1.1 deprecation earlier in lower environments for testing.

We call one Mule API from another using the Shared Load Balancer (SLB) URL and the HTTPS Request connector, without a configured TLS Context. Will this continue to work?

Yes, it will continue to work as long as you do not upgrade to Mule 4.10 Edge. Earlier versions of Mule running on Java 8 or Java 17 default as a minimum to TLS 1.2

We use a TLS Context for HTTPS Listeners in all Mule APIs, with a self-signed certificate in the keystore and no explicit TLS version or cipher settings. Will this continue to work?

Yes, as long as you do not upgrade to Mule 4.10 Edge. Earlier versions of Mule with Java 8 or Java 17 default to TLS 1.2 as the minimum version.

Will outbound calls from MuleSoft to other systems (e.g., SFTP, Salesforce, databases) be impacted?

It depends on the connector:

• SFTP connector: Does not use TLS and is not impacted.

• Database connectors: Most likely Yes. These typically require explicit TLS configuration. In essence, it  depends on the specific database driver.

• Other connectors: If they use HTTPS/TLS internally and are configured for TLS 1.0 or 1.1, they will be impacted.

Testing which TLS version is used

Java SSL debug log

Java can generate logs that display the TLS version used by a Mule application when establishing a connection. Be aware that these logs can become very large if there is significant HTTPS traffic. For this reason, it is not recommended to enable this logging in production environments for extended periods.

To enable the SSL set the property javax.net.debug=ssl:handshake. For instructions see the article, How to enable SSL debug logging in MuleSoft Products. When there is an HTTPS request the log will show the version proposed by the client:

"ClientHello": {
     "client version" : "TLSv1.2",

Optionally, the client may send a list of supported versions:

"extensions" : [
  "supported_versions (43)": {
  "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]
},

The server will respond with its selected TLS version:

"ServerHello": {
     "server version" : "TLSv1.2",

In this example, both the client and the server support TLS 1.2.

Using Curl to test a server

If Curl is installed, you can use the verbose -v argument so Curl will show the TLS version used.
Example:

$ curl -vk https://localhost:8082
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / [blank] / UNDEF

The message indicates that TLS 1.2 is supported.

To verify if a server supports a specific TLS version use the arguments:

$ curl -vk -tlsv1.1 --tls-max 1.1 https://localhost:8082
...
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8082

This error shows that TLS 1.1 is not supported.

Note: Messages may change depending on the version of Curl used.

Using openssl to test a server

If openssl is installed in your system you can use it:

$ openssl s_client -connect localhost:8082 -tls1_1 -brief < /dev/null

Connecting to 127.0.0.1

001F37F201000000:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:ssl/statem/statem_lib.c:155:

The error shows that TLS 1.1 is not supported.

Note: in Windows remove < /dev/null from the end of the command line. You may need to use CONTROL-C to stop openssl.

Using Wireshark & Tcpdump on on prem applications

Use the tools Wireshark and Tcpdump to capture the connection’s traffic and analyze the TLS handshake in Wireshark UI. This is a complex tool and requires some familiarity with networking concepts to use it.

CloudHub 1.0

What is the actual change for Shared Load Balancer (SLB)?

Inbound connections using TLS version 1.0 and 1.1 to CloudHub 1.0 Shared Load Balancer will be blocked from week of 27 October 2025

Any changes to Dedicated Load Balancer (DLB)?

Effective December 1, 2025, customers won’t be able to configure TLS 1.1 or earlier in any new DLB created after that date across all Mule runtime versions. However, existing TLS 1.1 and 1.0 connections will continue to work until Oct 31, 2026. All existing DLB connections using TLS 1.1 or earlier will be stopped on Oct 31, 2026

What actions do customers need to take?

To avoid disruption, customers need to:
a) Update the configurations in their CloudHub 1.0 applications that are targeting (i.e. making a request via) SLB:

• Do not configure enabledProtocols and enabledCipherSuites; keep the default configuration. If these settings are currently configured in the application using SLB, please remove them.

• If it is necessary to specify these configurations, only use TLS 1.2.

b) If clients are using TLS <= 1.1 to make inbound connections to applications running on CloudHub 1.0 SLB, please instruct them to use TLS 1.2.

Changes to cipher suites for the SLB

These RSA-SHA256/GCM/SHA384 based cipher suites were not supported earlier but are now supported.

• TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048)

• TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048)

• TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048)

• TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048)
  
  

These older CBC-SHA (SHA-1) suites tied to TLS 1.1 and early TLS 1.2 were deprecated.

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1)

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1)

• TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048)

• TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048)
  
  

The following ciphers will continue to be supported

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1)

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1)

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1)

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1)

TLS Cipher Suites Comparison

CloudHub 2.0

What is the actual change for Cloudhub 2.0?

Since January 31, 2025, customers were no longer able to configure new TLS 1.1 ciphers via UI or API under CloudHub 2 Private Space TLS context (Runtime Manager -> Private Space -> Domains & TLS). Starting January 31 2026, even existing configurations and connections that were relying on TLS 1.1 will be blocked.

Are we updating the customer's Cloudhub 2 Private Space TLS context and removing TLS 1.1 ciphers from existing TLS contexts that are in use?

Yes, the update will remove existing TLS 1.1 ciphers from existing TLS contexts that are in use. Since Jan 2025, customers using TLS 1.1 ciphers were no longer able to view or edit their TLS 1.1 cipher configuration on UI or API. Any updates will need to be on TLS 1.2+ ciphers.

Will the current configuration using TLS 1.1 ciphers remain, and we are just removing the TLS 1.1 ciphers from all newly created TLS contexts?

Private Spaces with a customer's existing configuration using TLS 1.1 will no longer support TLS 1.1, resulting in TLS 1.1 traffic being blocked.

How is this change going into effect?

The change will take effect when the Private Space infrastructure is upgraded.

If I am using the TLS context with default ciphers. The default doesn't include any TLS 1.1 ciphers. Do I need to make any changes?

The default TLS context does not contain the ciphers that are being deprecated. The TLS 1.1 ciphers are only present if the customer created a TLS context and manually selected the TLS 1.1 ciphers Hence, there is no need to make any changes in the TLS context.

As an administrator on Anypoint Platform, how do I find all the applications that use the deprecated TLS 1.0 and 1.1 ciphers?

Customers need to check if their clients are specifying any TLS 1.1 ciphers while connecting to CH2 applications.

As an app owner for a large number of apps, is there a way for me to update my settings across all my apps to use the newer/supported TLS 1.2 and 1.3 standards without having to go through each app's UI settings?

Customers must remove all TLS1.1 ciphers from TLS Contexts. Applications behind those TLS Contexts will no longer support TLS1.1 ciphers.

I have many apps that are using TLS1.0 and TLS1.1 today. What actions should I take to update them to use the supported TLS versions?

Customers must remove all TLS1.1 ciphers from TLS Contexts. Applications behind those TLS Contexts will no longer support TLS1.1 ciphers.

Does this change impact application outbound connections to legacy endpoints, which still use TLS1.0 or TLS1.1?

There is no impact for outbound connections from within the Mule apps using runtime versions <4.10. For applications using 4.10 or greater, outbound connections using TLS 1.1 or 1.0 will be blocked.