I've created QPID-8404 for this and attached a very simple patch which I hope should solve your issue
-- Rob On Fri, 24 Jan 2020 at 10:43, Rob Godfrey <[email protected]> wrote: > It looks like this might be related to changes made in the underlying > Jetty library - https://github.com/eclipse/jetty.project/issues/3554 > > It seems like a change needs to be made to Qpid Broker-J to explicitly > disable this breaking change that Jetty introduced :-( > > -- Rob > > On Thu, 23 Jan 2020 at 21:48, David Gillingham - NOAA Affiliate > <[email protected]> wrote: > >> I am attempting to upgrade a project currently running QPID Broker-J 7.1.0 >> to 7.1.7 and have discovered a change to the certificate validation >> behavior that is breaking my application. >> From what I've been able to figure out, it appears that starting with >> release 7.1.5, when External Authentication is enabled, QPID now appears >> to >> attempt to match the hostname/IP address of any incoming connection to >> either the subject or CN inside the client-provided certificate. >> When attempting to make a REST API request using cURL on 7.1.5, I get the >> following error:$ curl --cacert root.crt --cert guest.crt --key guest.key >> https://dev25:8080/api/latest/queue >> curl: (35) SSL peer had some unspecified issue with the certificate it >> received. >> >> When I look at qpid.log, I found the following error:2020-01-23 >> 14:22:02,703 INFO [qtp1186859375-45] (o.a.q.s.m.p.HttpManagement) - TLS >> handshake failed: host='xxx.xxx.xxx.xxx', port=45572: >> javax.net.ssl.SSLHandshakeException: No subject alternative names present >> guest.crt/guest.key are an openssl generated cert/key pair adequate for >> user authentication purposes. The subject/CN refer to my user. >> >> If I instead use the same cert/key pair that I've configured for the QPID >> server, I can successfully get a response from the REST API. I assume this >> is because that cert has my system's hostname in the subject/CN. >> >> I cannot reproduce these issues on release 7.1.4 or earlier. >> >> Can someone explain why this change to certificate validation behavior was >> made and why it would be desirable? From my prior experience with >> interacting with web applications that required certificates for >> authentication, hostname checking was never part of the requirement. This >> makes using new versions of QPID difficult as we'd have to generate a >> large >> number of new certificates for every host that connects to QPID instead of >> letting users use their personal certificate. >> >
