[jira] [Commented] (TS-3599) Multiple dest_ip=* directives has unpredictable behavior in ssl_multicert.config

["Susan Hinrichs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547260#comment-14547260 ] 

Susan Hinrichs commented on TS-3599:
------------------------------------

I think some of what you were seeing was due to flaws from TS-3597.  With that bug, the SNI logic was not triggering correctly if accept_threads were disabled.  In that case, the default context was always used.

The ssl_multicert.config loader assigns entries with dest_ip=* to the default_context.  If there are multiple, only one wins (last in the file I'd assume based on looking at the code).

The default context is used if there is no SNI (but the SNI callback in ATS should always be called as long as there is not a bug) or if nothing better matched on name or IP.

Should we issue a warning or error if there are multiple dest_ip=*?  Or other IP conflicts?

> Multiple dest_ip=* directives has unpredictable behavior in ssl_multicert.config
> --------------------------------------------------------------------------------
>
>                 Key: TS-3599
>                 URL: https://issues.apache.org/jira/browse/TS-3599
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: SSL
>            Reporter: Leif Hedstrom
>             Fix For: 6.0.0
>
>
> If I create an ssl_multicert.config with e.g.
> {code}
> dest_ip=* ssl_key_name=foo.key ssl_cert_name=foo.crt
> dest_ip=* ssl_key_name=bar.key ssl_cert_name=bar.crt
> {code}
> Then even with an SNI enabled client, which uses SNI in the TLS handshake, ATS seems to arbitrarily pick a cert. This seems nonsensical, I get the impression that dest_ip=<anything> would only take effect if there is no SNI in the handshake?
> I understand that more than one dest_ip=* is perhaps not a valid configuration, but in that case we ought to either error out (fail to start), or at least produce a really loud warning.  Clearly making it fail like this seems unreasonable :).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)