Action Required: Update TLS Configuration for VA Connectivity

Description

As part of SailPoint’s ongoing commitment to strong security practices, the Java runtime used by the SailPoint Virtual Appliance (VA) has been upgraded to Java 17.0.18 . This upgrade aligns the platform with modern cryptographic standards defined by the Java ecosystem and broader industry security guidelines.

However, this change may impact connectivity with systems that still rely on Unsupported JVM TLS encryption algorithms. To ensure uninterrupted operation, we are providing temporary compatibility support , but customers will need to update their target systems within the next 30 days.

Why This Change Matters

Modern security standards are continuously evolving to protect against emerging threats and cryptographic weaknesses. One such example is the deprecation of SHA-1 based TLS handshake signature algorithms. SHA-1 has been considered cryptographically weak for several years, and industry standards bodies and software vendors are actively removing support for it.

Beginning with Java 17.0.18, the Java runtime disables SHA-1 handshake signature algorithms by default for TLS 1.2 and DTLS 1.2 connections. This includes algorithms such as:

  • rsa_pkcs1_sha1
  • ecdsa_sha1
  • dsa_sha1

Disabling these algorithms strengthens the security posture of the platform and ensures SailPoint customers remain aligned with modern cryptographic standards.

What This Means for Customers

After the Java upgrades to Java 17.0.18 in VA, some customers may experience TLS/SSL handshake failures when the SailPoint Virtual Appliance connects to systems that still rely on SHA-1 handshake signatures. These failures may include:

  • Failed Test Connection operations
  • Aggregation failures
  • Provisioning failures
  • TLS errors during connector communication

A Typical error message may include:

  • Received fatal alert: handshake_failure
  • SSLHandshakeException
  • The driver could not establish a secure connection

In most cases, the issue originates from the target system or intermediary components such as load balancers, reverse proxies, or SSL inspection devices that still negotiate SHA-1 handshake signatures.

Compatibility Support

To help customers maintain business continuity while making the necessary updates, SailPoint has added updates to the recent virtual appliance releases. These releases introduce 30 days of compatibility support that allows legacy SHA-1 handshake signatures when required.

This temporary mitigation:

  • :white_check_mark: Restores connectivity for impacted integrations
  • :warning: Re-enables deprecated cryptography and should only be used as a short-term bridge
  • :spiral_calendar: To maintain a strong security posture, this compatibility support will be removed after 30 days, valid until 10th April 2026

What Customers Need to Do in the Next 30 Days

Before April 10th, customers must update the TLS configuration of affected systems to support secure cryptographic signature algorithms.

Customers can remediate this by:

  1. Updating the TLS configuration on the target application or database server
  2. Ensuring the endpoint supports TLS 1.2 with SHA-256+ handshake signatures
  3. Applying vendor patches or platform upgrades if the system is outdated
  4. Reviewing TLS configuration on infrastructure components such as:
  5. Load balancers
  6. Reverse proxies
  7. SSL inspection appliances

These changes ensure compatibility with modern Java security configurations while improving the security posture of connected systems.

Timeline Details

Calendar

:bangbang: By RSVP’ing to this event you will be reminded of this release prior.

  • A temporary compatibility support is added to the VA systems for the next 30 days, until April 10th
  • Within 30 days, customers must upgrade affected systems to modern TLS handshake signature algorithms
  • After 30 days i.e., April 10th, the temporary compatibility support will be removed

After the 30-day window, environments that have not updated their TLS configuration may experience connection failures again. For additional information, review the official Java release documentation:

Frequently Asked Questions

Is TLS 1.2 being deprecated?

No. TLS 1.2 remains fully supported. The change only affects SHA-1-based handshake signatures within TLS 1.2/DTLS 1.2 connections, as well as legacy cipher suites that do not preserve forward-secrecy. To ensure compatibility, update your systems to use modern ciphers.
Examples of Supported (Secure) Cipher Suites:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Examples of Deprecated (Weak) Cipher Suites that will FAIL:

  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

For more information please refer: Oracle Java SE Development Kit – Java 17.0.18 Release Notes

Why can’t SailPoint keep the compatibility support permanently?

The compatibility support re-enables legacy cryptographic algorithms that are no longer considered secure. Maintaining this long-term would weaken platform security and conflict with modern industry standards.

What if we cannot update our system immediately?

If your target system relies on non-secure cryptographic algorithms (like SHA-1) and is not updated, every operation for that specific connector—including Test Connections, Aggregations, and Provisioning—will completely fail due to rejected network connections.

If you face issues in connecting ISC with the respective managed system after making the suggested updates, please contact the SailPoint support team.

2 Likes

Hi, how do we validate that the ‘Test Connection’ is working with source systems as soon as possible if SailPoint is allowing compatibility until April 10th?

3 Likes

I agree with Will - how the heck can we test this before?

Hi, how do we get to check this and update it?

I also agree, there has to be something or someway for us to be able to verify its going to work.

In addition, the post says 30 days, but it was posted March 18th. April 10th is much sooner than 30 days.

2 Likes

Would it be feasible to at least schedule/coordinate temporarily disabling the backwards compatibility in our non-prod tenant for some initial testing and validation?

@community_managers Good morning - hoping to get some feedback on this thread - as this seems to be a change with a wide range of impact, and no way to test these changes to confirm if folks are impacted.

Thank you - and hope you folks have a great day.

Hi @Crimson3708 , I’ve made the product management team aware of the questions on this post and asked for some more feedback, stay tuned!

3 Likes

Is there a way to identify all impacted sources/connectors in ISC that still rely on SHA-1 TLS handshake before failures occur

Hi All,

Please find below inputs:

  • A periodic health check is done on all the ISC sources, which raises a flag in case of any issues. This will ensure your existing sources are working fine
    • The first release will be made in the ISC Sandbox.
    • This will provide enough time for customers to identify the impacted sources.
  • Users can also run a test connection in their sandbox if an explicit check is necessary
  • This is a change made by Oracle (JDK updates are released by Oracle). Please work with the respective application provider (the manage system with which the source is integrated) to ensure that they are running on the appropriate ciphers as mentioned in the blog post

Please feel free to reach out to SailPoint support if you still have any open queries.

Please find below inputs:

  • A periodic health check is done on all the ISC sources, which raises a flag in case of any issues. This will ensure your existing sources are working fine

    • The first release will be made in the ISC Sandbox.

    • This will provide enough time for customers to identify the impacted sources.

  • Users can also run a test connection in their sandbox if an explicit check is necessary

  • This is a change made by Oracle (JDK updates are released by Oracle). Please work with the respective application provider (the manage system with which the source is integrated) to ensure that they are running on the appropriate ciphers as mentioned in the blog post

Please feel free to reach out to SailPoint support if you still have any open queries.

I see the below message in VA’s.

Disk volume /etc at 0% free

Rebooting the VA did not solve it.

Out of curiosity, you say the first release will be made in the ISC Sandbox. Is it already live? Or when will this be active in sandbox so we can verify.

This isn’t live yet and will likely be released sometime after April 10th.

You say that this is going to be effective for prod & sb effective april 10th. How can we test this prior to the 10th?

You are effectively saying that we have no way to test this before it goes into effect.

2 Likes

We will release in sandbox first and then to production. Customer will get 14 days to test this in Sandbox and report if any issues observed.

conflicted message

announcement said already deployed and cut off it 10 Apr.

then another reply said first release in Sandbox, then 14 days in production. but cut off is in 30 days / 10 April form first release in sandbox (so 14 days for prod)?

Timeline for SailPoint customers to update the TLS configuration of affected systems in production (which could be 10 or hundreds) within less than 14/30 days is unrealistic.

improvement can be made on what exactly “A periodic health check is done on all the ISC sources, which raises a flag in case of any issues” to be check (source status?)

Please find below inputs:

  • A periodic health check is done on all the ISC sources, which raises a flag in case of any issues. This will ensure your existing sources are working fine

    • The first release will be made in the ISC Sandbox.

    • This will provide enough time for customers to identify the impacted sources.

  • Users can also run a test connection in their sandbox if an explicit check is necessary

  • This is a change made by Oracle (JDK updates are released by Oracle). Please work with the respective application provider (the manage system with which the source is integrated) to ensure that they are running on the appropriate ciphers as mentioned in the blog post

The current timeline:

  • Sandbox release date - 14th April

  • Prod release date - 28th April

Please feel free to reach out to SailPoint support if you still have any open queries.

The current timeline:

  • Sandbox release date - 14th April

  • Prod release date - 28th April

Please feel free to reach out to SailPoint support if you still have any open queries.

Do you if the SailPoint released connectors are impacted?

Epic EMP

Epic SER

Workday

onPrem AD

Entra AD

I see TLS mentioned in them but not what version or how the handshake happens.