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.

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

Yes, it would @Mark Takata (Adobe) can you push out a cf update today with that please? 😜

or being able to provide the certs per cfhttp request would be awesome too. many other languages have that feature.

doesn't cfhttp have that?

yeah, thats for when you need to have a client side cert for authentication

@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.

Drink the beer before it gets warm

Beer can get warm? Guess I've never had any last that long.

Yeah, mine rarely makes it into the fridge.

yes, my bad - I meant specifically "certificate pinning".

In before Adam gets here to tell us how Guinness should be consumed at room temp.

Cellar temperature. Room temp would be too warm. Shouldn't be chilled though.

I like the cut of your jib sire.

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?

That sounds like an edge case. In the bug report literally it says "this is not a simple reproducible case"

I had to change that setting too when smarty.com - In my case I specified jvm to use 1.2

setting those jvm arguments resolved the issue

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?

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.