trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: ssl_multicert.config issue.
Date Tue, 24 Jul 2012 05:26:03 GMT
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.
> 


Mime
View raw message