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.
