On Feb 1, 2014, at 9:27 PM, Leif Hedstrom <[email protected]> wrote: > 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”).
Oh I remember that we broke you last time we touched this code too :) SNI collisions now generate warnings, so that's good. I think that the right solution to your configuration is to explicitly configure the SNI names in ssl_multicert.config as Harald suggested in a different thread. If we are concerned about upgrade compatibility we ought to retain the warning and continue to overwrite the index entry. J
