[
https://issues.apache.org/jira/browse/TS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878448#comment-13878448
]
Feifei Cai commented on TS-2031:
--------------------------------
Hi Leif,
I attached a small patch for this issue.
iocore/net/SSLCertLookup.cc
I check the insert result or lookup it in advance. If the same hostname is
found, I add a warning in the log.
iocore/net/SSLUtils.cc
Update a comment. We actually have deal with wildcards now.
Although this patch can warn on same hostname now, I have a question about the
logic in SSLCertLookup.cc :
When we store subject CN and subjectAltNames DSN, we use 2 data structure:
1. For hostnames without wildcard (e.g. www.example.com), we insert in hash
table.
https://github.com/apache/trafficserver/blob/master/lib/ts/ink_hash_table.cc#L312
2. For hostnames contains wildcard (e.g. *.example.com), we insert in trie.
https://github.com/apache/trafficserver/blob/master/lib/ts/Trie.h#L144
When we insert a hostname for multiple times, the insert logic is different. In
hash table, it will replace any previous binding values for the key; but in
trie, it can not insert duplicated value and will print Debug message into log
file and return false. I think we should keep a uniform logic here, and, I
prefer the logic of hash table.
Because of these 2 different logic, my patch gives 2 different warnings, which
may confuse our customers. If we keep a uniform logic, then we can give uniform
warnings. What's more, we can move warnings outside SSLCertLookup.cc, into
SSLUtils.cc, then we can print warnings with certfile names instead of SSL_CTX.
Then customers can know which certfile wins and which certfile is overwritten.
https://github.com/apache/trafficserver/blob/master/iocore/net/SSLUtils.cc#L617
We also should keep in mind that most certs include CN in subjectAltName DNSs,
e.g.
CN:
*.example.com
subjectAltName:
DNS *.example.com
DNS www.example.com
So multiple insertion almost always occurs when parse certfiles with
subjectAltNames extensions, we should not warn on this condition.
Would you please help confirm the insert logic? If you agree to keep a uniform
logic, which do you prefer? I'll propose another patch according to your
advice. If not, please review the attached patch.
Thank you!
> Two SSL certs with overlapping CNs stomps over each other without warnings
> --------------------------------------------------------------------------
>
> Key: TS-2031
> URL: https://issues.apache.org/jira/browse/TS-2031
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
> Reporter: Leif Hedstrom
> Priority: Minor
> Fix For: 5.1.0
>
> Attachments: TS-2031.diff
>
>
> If you have two certs that has the same CNs, the last one wins in the SNI
> negotiation. This even takes precedence over "assigned" IPs (SNI trumps IP).
> We should at least warn on this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
