http://coldfusion.com logo
Join SlackCommunities
Powered by
Has anybody seen an issue in ColdFusion 21 on Wind...
# adobe
p
Has anybody seen an issue in ColdFusion 21 on Windows Server where the CFHTTP tag refuses to connect over HTTPS? We keep seeing errors like this:
Copy code
I/O Exception: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
b
@Patrick S Can you paste the FULL stack trace. Often times these errors have a "caused by" with more info.
d
It sounds like this is a TLS or SSL cipher issue. It might be related to the JVM.
p
Yeah, it seems to be the case, the hosting company had set our production servers set to use PCI 3.2 instead of the ColdFusion defaults, which apparently breaks when trying to connect to no-name APIs like google and twitter...
t
I've run into lots of errors with CF2021 and https connections. The GUI installer ships with jdk 11.0.2 which had some bugs with https -- upgrading to something recent will fix those. Also if you have a data source that makes an encrypted connection to SQL Server, it for some reason breaks all other https communication in CF. Adobe has a patch for that one.
p
Hi All, I have shared the patch with Patrick
b
So, this is a known issue?
Can we have a link to the bug tracker item for it?
p
Not everyone reported this issue.
b
Huh? that's not what I asked
p
This with random users. It was difficult to reproduce the issue
b
I just asked if it was known
Where is the ticket for it so we can read up on it
p
yes, it is a known issue
I have to make it public after the discussion
b
Searching the bug tracker for 
NoSuchAlgorithmException
gives no results
I don't understand why there would be a ticket that wasn't public by default, unless there was some security concernm
p
I don't think there is any security concern
b
Then it doesn't make any sense to have known documented bugs hiding in a "private" tracker that the community can't find.
p
@bdw429s This will be part of the upcoming update so it will eventually be public.
b
Right, but my point here which seems to be getting lost is there shouldn't be such a thing as a ticket that becomes "eventually" public. (with the exception of security concerns) All tickets should start day 1 in the public bug tracker. As in, they should be logged there right away at the start so there's no need to go back and make anything "public" after the fact.
In this example, the OP could have found this issue right away by just searching Adobe's bug tracker for his error message had Adobe logged it properly in the first place.
p
I logged this bug and as you know, any bug that logged by us(CF team) will not be public by default because there are cases which is specific to certain customer and we don't want them to be public.
b
as you know, any bug that logged by us(CF team) will not be public by default
No, I didn't know that at all! That's why I'm so surprised to hear it. I log tickets for ColdBox or CommandBox all the time on behalf of customers, many times via support contracts, and I do so • in our public bug tracker • without any private details My E-mails or messages with the client in whatever support channel are separate from the bug itself which contains a simple repro case fit for anyone to look at.
All I'm saying here is there is room for improvement on this. I am not a fan of having a public and private side to any bug tracker when it comes to just ordinary bugs where the precedes of that information can be helpful to the community. A public-by-default stance provides the most value for your users.
cc @Aditya Nema ☝️
p
I agree to your point and point taken indeed. I will raise this and will see if we can do something about it. P.S. Aditya is no longer with CF team, he moved to different team recently.
b
WUT? Wow, that is... surprising and honestly a little disconcerting news 😕 Thank you for listening-- I know you have the best for CF in mind.
Open in Slack
PreviousNext
Powered by