On 4 June 2015 at 10:12, Erik Aschenbrenner <[email protected]> wrote: > Ok, if found out, that the problem is the the servers certificate doesn't > match is host name as described in this stackoverflow question > <http://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found> > . > > The CN (Common Name ) of the servers certificate is set to the servers DNS > (e.g. CN=some.remote.host) and if I'm using the IP in the connection URI, > than the certificate check fails. > > If I'm using the servers DNS in the connection URI, connecting works. > > The question is, why this wasn't a problem with the old client API? Or is it > a convention, that a certificates CN has to be its domain name? >
The host name verification isn't enabled in the old client (we should probably add an option to enable it if we do another maintenance release). In the new client it can be turned off by setting the transport.verifyHost option as detailed in the documentation Robbie pointed to. -- Rob > Regards, > Erik > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Changing-from-old-Qpid-JMS-client-to-Qpid-JMS-0-2-0-tp7625652p7625811.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
