On Feb 1, 2014, at 8:49 PM, James Peach <[email protected]> wrote: > On Feb 1, 2014, at 11:53 AM, Leif Hedstrom <[email protected]> wrote: > >> >> >>> On Feb 1, 2014, at 11:54 AM, James Peach <[email protected]> wrote: >>> change, I have to reorder the two lines in the config, to get expected >>> behavior. > > If order matters, or the longest match is chosen it is a bug. > ci/tsqa/test-ssl-certificates is a very basic certificate matching test and > this passes for me.
Aha, I think I know what’s going on, the two certs actually have an overlap on www.ogre.com. What has changed in the code is the order priority when this happens. My two certs are as follows: 1. This is a cert generated by a trusted CA (Go Daddy): Common names www.ogre.com Alternative names www.ogre.com ogre.com cosmo.ogre.com www.boot.org www.ogrephotography.com www.slapi.com 2. This is my self signed (untrusted) cert: Common names www.ogre.com Alternative names *.ogre.com *.ogreimg.com *.boot.org *.slapi.com *.ogrephotography.com *.wyner.org We can argue about the correctness in my setup, and I can certainly generate a new self-signed cert (or fix my ATS config, which I did). But for sure, the order of the certs as specified in ssl_multicert has changed :). I agree that the new behavior is a hell of a lot more reasonable (priority by order, “first cert wins”)), but it is in fact incompatible with v4.1.3 (which had “last cert wins”). Cheers, — leif
