We’re excited to share that JDK 17 is now supported in the Cloud Connector Gateway (CCG), upgraded from the previous JDK 11 version. This update brings improved performance and enhanced security for customers using CCG.
Benefits
Performance Improvements.
Enhanced Security over JDK 11.
Action Required
Customers using custom VA-based connectors or connector-specific rules should validate them against JDK 17 to ensure compatibility. There are chances where it might be affected in rare scenarios where there is a strictly compatible with JDK 11 (only).
Important Dates
Sandbox Release: September 15, 2025
Product Release: October 29, 2025 (CCG Version-1164)
Glad to see something here to at least mention what we were seeing in that incessant popup the other day in ISC, but this still doesn’t give very much detail or really explain what the impact is to administrators.
Does this mean Java 11 is no longer supported, and any custom rules need to be tested against Java 17 to ensure they won’t break in production 2 weeks from now?
It would be helpful to give descriptions of the functional differences or at least link to documentation that may indicate what changes may be needed to rules.
Yes, some more context on this as well as potential impact might be good. See also my forum post here:
As mentioned in that topic it would be good to understand why this wasn’t shared earlier? Sandbox is already updated? Perhaps it was a good idea to raise that this is going to happen a few months in advance?
Can the deadline of October 6th be pushed backwards? Would pinning the CCG version help?
It seems that this process was not properly taking into account the actual customers and implementation partners.
This announcement was made days after this functionality was deployed in sandbox environment. Customers who had scheduled meetings for user acceptance testing would need to cancel it since the planned source onboarding suddenly fails due to this unexpected update messing up the custom rules. Only later they would receive the announcement.
The upcoming month probably have been planned for other activities by now that now would need to be delayed/replanned as immediate action is required to ensure these updates from SailPoint are not breaking functionality that is being relied on for months/years already.
The announcement does not mention if or how customers can postpone this update from their side, such that they can evaluate and prepare for it during a time that works for them. Who knows perhaps their key custom rule writers are on a holiday these three weeks. Should they now be called back from their holiday due to this sudden announcement mentioning the functionality could break?
FYI, for those noticing that the creation date of this post is September 10th. This is not matching when this announcement got published, which was just 15 hours ago since I posted this comment.
Are there any issues known with JDK 17 update and SQLLoader source connector?
Since Sept 16th, 12:00 CET our SQLLoader sources are not working in Sailpoint Sandbox. The problem started immediately after JDK was updated to version 17
Nothing changed on our side, path, user credentails etc.
I suppose it could have somehting to do with “Enhanced Security over JDK 11.”
error:
Error Received:
[ ConnectionFailedException ] [ Possible suggestions ] Verify that Connection User and Password are correct. [ Error details ] Error occurred while establishing the connection with Data File during test configuration operation. Failed to load table
Would it be possible to initiate a conversation in this thread or in the thread linked below on the concerns raised? I don’t like this radio silence on this casually mentioned but not so trivial pending upgrade.
I’ve spoken with a few folks internally and can see that this update was mainly made due to security vulnerabilities CVE-2024-12798 and CVE-2024-12801.
If you need more time to test, pinning the CCG to version 1120 will stop this update. You wont receive any updates security or otherwise until it is unpinned.
There are not any that we know of, we have been monitoring logs. With that being said, we are looking into SQLLoader specifically to ensure everything is working as expected.
I’ll let Dinesh provide any other additional details.
Hi @vasilcin3, Could you please raise a support ticket to investigate on it further. If you have already raise the support ticket, please let us know the support ticket ID. We investigated the details and confirmed that it is working fine in our environment. So, we need additional details for the investigation.
Hi @sup3rmark, as mentioned in the blog, if you have any connector specific rules which is tightly coupled with JDK 11 (which should not be the case in general), then that needs to be compatible with JDK 17. There is no impact for Cloud rules or any other custom rules if you are referring that as a cloud rule.
Only custom VA-based connectors or connector-specific rules needs to be validated, it depends on the custom code written in rule if that is not compatible with JDK 17.
Hi @tyler_mairose thanks for the more detailed description.
We will discuss within our team if we see a need to pin the CCG version to give us more testing / redevelopment time if needed. But since it now addresses two CVE’s, I think it is prudent to get that updated asap.
One question / concern hasn’t been answered yet. Why is the lead time for announcing this update so short? This gives any company that uses ISC such a short time to address the issue, even if stated that it probably only impacts rare use cases.
And this is not the first time that there was no prior announcement made or no announcement made up front at all. I don’t think this is the proper way forward for a company such as SailPoint.
Thank you, @sauvee. We completely understand your concern regarding the timeline and recognize the impact this may have. Please know that we are doing everything we can to notify our customers as early as possible, ensuring smooth business continuity during such situations.
Unfortunately, this is an uncommon situation, and based on our change policy, the current timeline is the best we can provide. We’re unable to combine other fixes with this one, and as a result, we are unable to roll out any impacted changes until this version is successfully released to both the sandbox and production environments.
Generally, for CCG releases, we follow a two-week timeframe, and in this case, we’re extending that slightly given the nature of the impact. JDK upgrades, in particular, are infrequent updates, and we’re committed to ensuring the process goes as smoothly as possible.
We truly appreciate your understanding and patience as we work to support your success. Thank you again for working with us through this. Please feel free to reached out us if you need more time for validations in this case.
This is clear, and I understand it is an important update to further update the VAs.
I understand the ‘normal’ way of working is a two-week timeframe. But honestly, to counter that, those updates are typically of the sort where we don’t expect impact on our connectivity / logic. This time however, it is mentioned that there might be impact when using specific code that is not compatible with the newer JDK version. I believe that it should’ve been considered to have a longer lead time in these types of cases. Additionally, we have only received more context on the actual update when asking for more clarification and/or information. Perhaps it is a good idea for future updates to give more context, so we can better understand the update?
we have raised CS0410506 for this.
For us it seems jdk17 is handling some certificates differently.
As we see some cert errors (only in SB environment). The certificates are the same as before. And the same certificates work in PROD environment with jdk11 correctly. And Authenticate to the same server. Without the issue.
We see some errors like:
/usr/local/share/ca-certificates/: Is a directory
/home/sailpoint/certificates/xyz.pem is not a valid certificate
unable to load certificate
140452386961312:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
/home/sailpoint/certificates/xyz2.pem is not a valid certificate
UPDATE:
we have resolved the cert. errors in ccg-start.log above on our side. And restarted the VA’s.
The errors are gone in log. So they were not related to the issue.
But the connection to SQLLoader source is still not working.
Our JDBC connector started experiencing problems in sandbox, with the same situation, no code changes to it. The connector works in our production tenant, and if I was a betting person, I’m guessing on the 6th, this will fail too.
What I’m confused about is that it maps the attributes from the request with setString, to pass the attributes in the correct index order for the stored procedure the provisioning rule calls. It gets to the 10th index, skipping indexes from 11-17 and then immediately attempts to run the stored procedure, returning a Data Truncation error from the JDBC driver.
I’ve been reviewing major changes that could affect this setString method from 11 to 17, but nothing pops out.
I am making a support case, but it’s going to be very unfortunate, if we are asked to engage Expert Services for a change that was forced in a small window where we have no control over.
Could you please give more details about custom VA-based connectors or connector-specific rules ?
Does this mean we need to validate all our before \ after operation rules ? Does a standard Web Services connector (through VA) must be tested too following this upgrade ?