During an SSL SOAP request: SSLHandshake.consume ignores value of com.sun.jndi.ldap.object.disableendpointidentification
Asked Answered
R

0

0

Clarification A: Since this is an SSL question, I hope I can lower the obvious security red flags and potentially save the time of our resident SSL security experts, by stating the following:

  1. This SSL communication is between a test machine and a product deployment that is not ready for final security work (ie: after initial testing is complete, a security team will fix all the certificates, ports, settings, etc...)
  2. At this point, both test client and test target machines are far less "mission critical" than the office coffee machine. We don't care if they get hacked, the data inside has no stealing/ransoming worth
  3. Everything is done within a local network that does not have any physical connection to the internet

Clarification B: While the obvious answer would be "have your devops finally manage to create machines without broken certificates" - well, we are not that evolved yet :) Also, if Postman and SoapUI can do this, I think it's important that the Java programming community knows how to do this too!


Now, to the question: I am getting: java.security.cert.CertificateException: No subject alternative DNS name matching beta-automaton-api.localnet found

I've found google results and SO questions such as: https://mcmap.net/q/1634380/-issue-with-dns-naming-and-certificates-ldap-context/51646182?r=SearchResults&s=5|11.6157#51646182

Where the "temporary patch, don't push this to production" is to start java with:
-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

However, I am still getting the same exception... I am even checking inside the SOAP client: System.getProperty"com.sun.jndi.ldap.object.disableEndpointIdentification"); // true

  • Using Java 1.8.0_261
  • The way I actually start java is that my "SOAP client" is actually a JUnit5 method in a maven project, under test source section... I have @Test annotation for the leading method and execute it with IntelliJ-IDEA's run configuration, where VM Options are:
    -ea -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

Any ideas why this "patch trick" with -D...disableEndpointIdentification doesn't work for me?

Rain answered 29/10, 2020 at 12:3 Comment(5)
Have you solved the problem?Underworld
@WakaWaka Yes. Why do you ask? :)Rain
Faced the same problem. If you remember how you managed to solve it, I will be grateful for your help. ;-)Underworld
yeah, it's 5 copied classes, one of them slightly hacked... Then 3 more classes added on top, to kinda make standard library java classes nice to use :) I don't think I remember everything - even if I can show it here (which I can't as it would be a few hours of editing text)... Doesn't your 'HttpSoapClient' (or however you called yours) invoke methods from 'HttpSoapConnection'? If that is the case, you can force-step-into and see the validation fail yourself. It's about 4 classes deep... Have a pen and paper ready! I am a pretty weak programmer and I managed - you will manage too!Rain
actually, if you are stuck and have a bit of a budget, I can help you with this personally (but I have to charge). Reach out on [email protected] if you are interestedRain

© 2022 - 2024 — McMap. All rights reserved.