On Feb 1, 2014, at 7:49 PM, James Peach <jpe...@apache.org> wrote: > On Feb 1, 2014, at 11:53 AM, Leif Hedstrom <zw...@apache.org> wrote: > >> >> >>> On Feb 1, 2014, at 11:54 AM, James Peach <jpe...@apache.org> wrote: >>> >>>> On Feb 1, 2014, at 7:37 AM, Leif Hedstrom <zw...@apache.org> wrote: >>>> >>>> Hi all, >>>> >>>> I just upgraded to latest master, and noticed that our behavior has >>>> changed related to how certs are “negotiated”. This is related to TS-2031 >>>> I believe. >>>> >>>> What it meant for me was that I had to reorder a couple of rules in >>>> ssl_multicert.config for the sites to work as expected. I’m sure this is a >>>> pretty unusual case, so I’m probably ok to just document this (visibly, in >>>> the v4.2.0 release) notes. But I’m interested to hear what others using >>>> SSL has to say about this? It technically does break backwards >>>> compatibility, since a config that used to work with v4.1.3 will not work >>>> with v4.2.0. >>>> >>>> Or should we play it safe, and move TS-2031 over to 5.0.x ? >>> >>> I'm not very clear on what happened; can you spell it out? >> >> >> I have two certs that matches www.ogre.com (one is is a wildcard). After >> this 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.
is *NOT* chosen :) > ci/tsqa/test-ssl-certificates is a very basic certificate matching test and > this passes for me. > > J
