Re: ssl_multicert.config issue.

[James Peach <jp...@apache.org>]

On 25/07/2012, at 7:36 AM, James Peach <jp...@apache.org> wrote:

> On 24/07/2012, at 6:16 AM, Todd Harpersberger <to...@ogilvy.com> 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 <jp...@apache.org> wrote:
>> 
>>> On 23/07/2012, at 8:32 PM, Todd Harpersberger <to...@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
>>>> <to...@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.
>>>> 
>>> 
>> 
>> -- 
>> 
>> 
>> 
>> 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.
>> 
>