On 25/07/2012, at 7:36 AM, James Peach <[email protected]> wrote: > On 24/07/2012, at 6:16 AM, Todd Harpersberger <[email protected]> > wrote: > >> That's great, thank you! Is there a jira bug created that I can track >> for a patch in the ip address match? > > nope, would you mind filing one and assigning it to me?
This should be fixed in https://issues.apache.org/jira/browse/TS-1392; please let me know if there's any problems J > >> >> -Todd >> >> >> >> On Jul 24, 2012, at 1:26 AM, James Peach <[email protected]> wrote: >> >>> On 23/07/2012, at 8:32 PM, Todd Harpersberger >>> <[email protected]> wrote: >>> >>>> Sure. Thanks for the response. Happy to provide whatever you'd like. >>>> >>>> They are all wildcard certs...We do a lot of web volume/tear-up tear down >>>> demos. >>>> >>>> Top cert is *.mycompany.com >>>> Then *.dev.mycompany.com >>>> *.qa.mycompany.com >>>> *.stage.mycompany.com >>>> >>>> I am assuming that SSL termination would be on the TrafficServer box, >>>> followed by a remap.config match to a backend host which would use an >>>> alias or hostheader. >>> >>> And while trying to explain the behaviour you are seeing I found that >>> there's another bug in the trie that we use to do a longest match on the >>> requested name. Thanks for reporting this :D >>> >>> I fixed this bug in https://issues.apache.org/jira/browse/TS-1380; I'll >>> take a look at the IP address match later in the week. >>> >>>> >>>> -----Original Message----- >>>> From: James Peach [mailto:[email protected]] >>>> Sent: Monday, July 23, 2012 11:28 PM >>>> To: [email protected] >>>> Subject: Re: ssl_multicert.config issue. >>>> >>>> On 23/07/2012, at 3:05 PM, Todd Harpersberger >>>> <[email protected]> wrote: >>>> >>>>> Running trafficserver 3.2.0 >>>>> >>>>> I'm trying to terminate multiple SSL cites on my traffic server but it >>>> always gives out the same (first) certificate. >>>>> There's nothing SSL from the default stated in the records.config, and >>>> the traffic.out log indicates that all certs are loaded. >>>>> >>>>> My ssl_multicert.config looks like: >>>>> >>>>> dest_ip=10.30.180.9 ssl_cert_name=mydomain.com.pem >>>>> dest_ip=10.30.180.10 ssl_cert_name=dev.mydomain.com.pem >>>>> >>>>> 10.30.180.9 and 10.30.180.10 are bound via separate interfaces. >>>>> >>>>> If I create a DNS records MYRECORD.dev.mydomain.com = 10.30.180.10 I >>>> still get the mydomain.com.pem cert. Is there any other config needed to >>>> parse this file? Or any other suggestions? >>>> >>>> If the client asks for a specific hostname, then we will serve the >>>> matching certificate before looking for the IP-based certificate. There's >>>> also a bug here, because it looks like we will fall back to the default >>>> certificate in the absence of a hostname match. We ought to fall back to >>>> the IP-based certificate first. >>>> >>>> Can you explain how your certificates are supposed to be used, so I can >>>> figure out whether you are hitting the above bug? >>>> >>>>> >>>>> Thanks! >>>>> >>>>> -Todd >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Privileged/Confidential Information may be contained in this message. >>>>> If you are not the addressee indicated in this message, you should >>>>> destroy this message. For more information on WPP's business ethical >>>>> standards and corporate responsibility policies, please refer to WPP's >>>> website. >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Privileged/Confidential Information may be contained in this message. If >>>> you are not the addressee indicated in this message, you should destroy >>>> this message. For more information on WPP's business ethical standards >>>> and corporate responsibility policies, please refer to WPP's website. >>>> >>> >> >> -- >> >> >> >> Privileged/Confidential Information may be contained in this message. If >> you are not the addressee indicated in this message, you should destroy >> this message. For more information on WPP's business ethical standards >> and corporate responsibility policies, please refer to WPP's website. >> >
