On 23/07/2012, at 8:32 PM, Todd Harpersberger <todd.harpersberger@ogilvy.com> 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:jpeach@apache.org]
> Sent: Monday, July 23, 2012 11:28 PM
> To: users@trafficserver.apache.org
> Subject: Re: ssl_multicert.config issue.
>
> On 23/07/2012, at 3:05 PM, Todd Harpersberger
> <todd.harpersberger@ogilvy.com> 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.
>
|