http://coldfusion.com logo
#cfml-general
Title
# cfml-general
s

Scott Bennett

06/13/2022, 4:15 PM
I am trying to debug a cfhttp issue on a dev environment, and the cfhttp is returning: "I/O Exception: Certificate for _--redacted--_.com doesn't match any of the subject alternative names: [*._--redacted--_ping.cloud]".... is there a way to disable the TLS cert checks/warnings in cfhttp for develpment purposes? a jvm setting maybe? The code has a cfoauth then after that a cfhttp runs to get user info from the sso api if the cfoauth is successfull. the first time through, the cfoath succeeds, but then the cfhttp fails with that error. then on subsequent requests the cfoauth failes until I restart CF serices. both the cfoauth and the cfhttp are pointing to the same domain. I am guessing there is a different server with a different certificate hosting the user info api requests, but once that one failes cf is somehow caching the bad certificate and causing the subsequent cfoauth requests to fail too.. or something equally confusing or mysterious to me. I have a ticket in with the owners of the sso system, however I was hoping I could bypass the checks for now to just keep working while they work out the certificate issue.
b

bhartsfield

06/13/2022, 4:34 PM
I don't know of a way to ignore invalid certs in CFHTTP specifically but adding the cert to the keystore would make it accept it as valid
a cert ignore on cfhttp would be fantastic for dev though
s

Scott Bennett

06/13/2022, 4:40 PM
Yes, it would @Mark Takata (Adobe) can you push out a cf update today with that please? 😜
🤣 1
d

Daniel Mejia

06/13/2022, 4:41 PM
or being able to provide the certs per cfhttp request would be awesome too. many other languages have that feature.
b

bhartsfield

06/13/2022, 4:44 PM
doesn't cfhttp have that?
I've never used the clientCert or clientCertPassword options of cfhttp but I assumed that's what they were for
ahh maybe not.
s

Scott Bennett

06/13/2022, 4:46 PM
yeah, thats for when you need to have a client side cert for authentication
I think I used that once
for some API
m

Mark Takata (Adobe)

06/13/2022, 4:47 PM
@Scott Bennett I just tried to push an update to the CF codebase and GIT refused my request and also defrosted my fridge. Please advise.
s

Scott Bennett

06/13/2022, 4:48 PM
Drink the beer before it gets warm
2
b

bhartsfield

06/13/2022, 4:49 PM
Beer can get warm? Guess I've never had any last that long.
r

rstewart

06/13/2022, 4:50 PM
Yeah, mine rarely makes it into the fridge.
🍺 1
d

Daniel Mejia

06/13/2022, 4:55 PM
yes, my bad - I meant specifically "certificate pinning".
m

Mark Takata (Adobe)

06/13/2022, 5:06 PM
In before Adam gets here to tell us how Guinness should be consumed at room temp.
🤮 1
a

Adam Cameron

06/13/2022, 5:09 PM
Cellar temperature. Room temp would be too warm. Shouldn't be chilled though.
2
That said... too much decent beer out there to spend too much time drinking Guinness unless it's an emergency.
Or breakfast at an airport.
m

Mark Takata (Adobe)

06/13/2022, 5:14 PM
I like the cut of your jib sire.
🍺 1
s

Scott Bennett

06/13/2022, 5:15 PM
so I heard back from the sso product owners and they thinking it is a tls 1.3 compatibility error and are asking if I can force 1.2... is there a way (in ACF 2018 update 13) to force cfhttp to use tls 1.2?
and suggesting I update the jvm or force 1.2
I am not smart enough about tls to really know if there is any validity to their suggestion
m

Mark Takata (Adobe)

06/13/2022, 5:18 PM
That sounds like an edge case. In the bug report literally it says "this is not a simple reproducible case"
I pinged my engineers to see what they have to say about it. I'll let you know.
not sure if that 100% related, but it does look like there is a way to specify in the jvm arguments -Djdk.tls.client.protocols=TLSv1.2 -Dhttps.protocols=TLSv1.2
☝🏾 1
sound very similar as this particular sso integration has been working fine for years, and they updated their server environment over the weekend
d

Daniel Mejia

06/13/2022, 5:57 PM
I had to change that setting too when smarty.com - In my case I specified jvm to use 1.2
s

Scott Bennett

06/13/2022, 6:21 PM
setting those jvm arguments resolved the issue
❤️ 2
👍 1
@Mark Takata (Adobe) just curious... is adding an argument to the cfhttp tag (and cfoauth and anything else that does http requests) that forces a particular tls version for that request a realistic ask for the future? and if so, is it already on a roadmap of some sort? I really think that could be useful in these types of situations. effectively I have just forced all http requests from coldfusion in my application to use tls1.2 when in reality it is only this one that needed it. Other http requests were using 1.3 just fine.
or is this more of a thing that should work fine, but doesn't because of the jvm version that cf 2018.13 is on and maybe there should just be an update that updates the jvm to fix the bug
m

Mark Takata (Adobe)

06/14/2022, 7:58 PM
I mean, I'd say put in an FR with your use case & we can see how difficult it would be. This particular case feels like a one-off, as you'd usually want to use the latest TLS version for security's sake (except here where it is broken in the space you're working in) but I could even potentially see using this to, for example, test a version that's not the current one, try a new one, etc. Question though, when you set those JVM args did you have to bounce the server to have them take?
s

Scott Bennett

06/14/2022, 8:49 PM
In our case, we set the arguments in the relevant /opt/coldfsion2018/<instance>/bin/jvm.config files, then restarted the cf instances that were affected (only certain instances use this particular sso integration). I didn't even test the cfhttp to see if it would work without a restart, I just assumed from experience that a restart was required for that kind of change. Generally, it seems that the ssl certificates on the sso system are set up correctly (as all the other systems throughout our large organization that use the same SSO/oauth system were not experiencing this problem), but there is a bug in the jvm version that CF is using (https://bugs.openjdk.org/browse/JDK-8211806) that caused the http request to reject the certificate (I'm not an expert on that part, so that probably needs validation from the cf engineering team). Forcing the use of tls1.2 fixed the issue for this scenario where we were triggering that bug. The weird part about it to me was that cfoauth connected fine to the domain, but then the cfhttp did not like the certificate, and then after that first cfhttp request, none of the cfoauth requests worked until the cf instance was restarted. That inconsistency leads me to assume there is something in the cfoauth behind the scenes when it hits the oauth server that cfhttp does differently. but then the cfhttp perhaps cached some connection info to that domain that subsequent cfoauth requests picked up and that stopped them from working. To me, this kind of seems like a bug that should probably be resolved by upgrading the jvm from 11.0.1 to 11.0.2+ (like Charlie describes here: https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/), but I felt that just adding arguments to the jvm.config was more expedient to get the team of people that were waiting for this to be fixed to the point where they could log into the system. I may still initiate a jvm update for our servers, but that would have required a more thorough QA process for my team than I wanted to commit to yesterday for an urgent incident. In terms of Use case for a cfhttp feature change, I can see scenarios where a developer might want to ignore certificate warnings or test using a particular tls version (particularly in development environments). @bhartsfield suggested it above so I am sure that I am not the only one. I don't personally feel like it is something I would run into everyday by any means, but having more control over those things might come in handy from time to time.
8 Views