[
https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863185#comment-13863185
]
James Peach commented on TS-2480:
---------------------------------
It sounds like the problem is the order in which the SSL callbacks are invoked.
We used to do the address-based certificate selection first before hitting the
SNI callback, but later we consolidated that logic. If we break this logic
apart again, then you still have to deal with the case that the SNI callback
will select a different certificate.
Not sure how this is handled in other SSL servers, but maybe the SNI callback
should also reset any other necessary state.
> Choose the ip related SSL_CTX not the default when creating new ssl
> --------------------------------------------------------------------
>
> Key: TS-2480
> URL: https://issues.apache.org/jira/browse/TS-2480
> Project: Traffic Server
> Issue Type: Wish
> Components: SSL
> Reporter: Wei Sun
> Assignee: James Peach
> Fix For: 4.2.0
>
>
> When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX
> retrieved from the request when presenting session ticket or session id is
> not associated with any app data (certs, settings, etc), ats delays the
> association in SNI handling. So in the callback of
> SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the
> expected SSL_CTX, and session ticket handling will be degraded to the default
> behavior.
> I have a requirement of retrieving SSL_CTX during these two callback
> functions, probably I could workaround it by
> SSLCertificateConfig::acquire()->findInfoInHash(ip) in every callback and get
> the expected SSL_CTX. I'm wondering is it feasible to do it once in
> make_ssl_connection()? Is there any design consideration for being this
> (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it
> is needed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
