That's great, thank you! Is there a jira bug created that I can track for a patch in the ip address match?
-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.
