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