http://coldfusion.com logo
Join SlackCommunities
Powered by
We are getting "persuaded" to update our Java for ...
# adobe
m
We are getting "persuaded" to update our Java for CF 2021 Update 5 server. We are currently at JAVA SE 11.0.16.1 (LTS). We attempted a while back to go to JAVA SE 11.0.17 (LTS) but had errors so we went back to JAVA SE 11.0.16.1 (LTS). We just noticed there is JAVA SE 11.0.18 (LTS) available from the adobe DL page: https://helpx.adobe.com/coldfusion/kb/coldfusion-downloads.html#third_party Before we attempt has anyone else updated successfully or had issues? Thanks in advance
t
I haven't updated to 18 yet, but I've been running 17 without issues... What'd you run into?
☝🏻 1
☝️ 1
e
11.0.18 works without issue in enterprise production.
However with any software application, even if you have the same engines, after you put different drivers in the seat, you will not get the same result. Always test before deploy.
m
@Tim We had issues with TLS versions and calling API's via https.
Yep we are getting that error with Java 18. Actual error is: I/O Exception: Could not derive key
e
That all being said, if you post your CODE and the error log, its far more helpful than all of us just guessing.
m
Agreed. And that is a great article. We did and do import certificates. And usually when we forget we get: 
I/O Exception: sun.security.validator.ValidatorException: PKIX path building failed:
I/O Exception: peer not authenticated
But we are not getting those "specific" errors, granted could still be related. I think it is related to the crypto algorithms. None of the ColdFusion logs describe any error - they make the https request but don't see an error, we just get back an error in the response 
I/O Exception: Could not derive key
This is our current JVM settings: 
-server -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/sun.util.cldr=ALL-UNNAMED --add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED -XX:MaxMetaspaceSize=192m -XX:+UseParallelGC -Djdk.attach.allowAttachSelf=true -Dcoldfusion.home={application.home} -Djava.security.egd=/dev/urandom -Duser.language=en -Dcoldfusion.rootDir={application.home} -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.JavaUtilLog -Djava.util.logging.config.file={application.home}/lib/logging.properties -Djava.locale.providers=COMPAT,SPI -Dsun.font.layoutengine=icu -Dlog4j2.formatMsgNoLookups=true -Dcoldfusion.datemask.useDasdayofmonth=true -Dcoldfusion.xml.allowPathCharacters=true -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2"
I have tried to remove the https.protocols completely I have added 
-Djdk.tls.client.protocols=TLSv1.2
I also commented out the disabled algorithms in the security.conf for SHA1
Update: Finally solved this issue, this probably wont affect anyone else, but I wanted to close this issue, I hope. We put in place to change the order of security providers for a similar HTTPS/SSL issue (probably 7-9 years ago). I commented out this code and it seems to have fixed the issue.
Copy code
<!--- rearrange security libs to avoid SSL error on some certs --->
<cfif NOT isDefined("application.jsafeFix")>
    <cfset objSecurity = createObject("java", "java.security.Security") />
    <cfset storeProvider = objSecurity.getProvider("JsafeJCE") />
    <cfset objSecurity.removeProvider("JsafeJCE") />
    <cfset objSecurity.insertProviderAt(storeProvider, 2) />
    <cfset application.jsafeFix = true />
</cfif>
3 Views
Open in Slack
PreviousNext
Powered by