Explain ATS's default SSL cert selection criteria

[jacksontj]

No description provided.

[jpeach]

That's not how it works. In all cases, we should be taking the longest match. If multiple certificates have the same matching specifier we should be issuing a warning and not loading the certificate.

[jacksontj]

Well, this is how it works regardless of how it should work...

But you should be able to specify multiple certs for a given IP (for
example) so sni clients can get the correct cert. It also makes sense to
have a fallback cert for clients that connect to such an IP and don't
support sni
On Sep 24, 2014 8:13 PM, "James Peach" notifications@github.com wrote:

That's not how it works. In all cases, we should be taking the longest
match. If multiple certificates have the same matching specifier we should
be issuing a warning and not loading the certificate.

—
Reply to this email directly or view it on GitHub
#121 (comment).

[jpeach]

Each certificate is indexed by the subject CN, all the alternate names and the IP address given in ssl_multicert. When we try to match the client connection, we match the SNI name first, then fall back to the IP address.

[jacksontj]

But what happens if there are 2 found for the same IP address? Which one is
the fallback? That's all I'm trying to document is that there is an order
in which one is the fallback.
On Sep 24, 2014 8:55 PM, "James Peach" notifications@github.com wrote:

Each certificate is indexed by the subject CN, all the alternate names and
the IP address given in ssl_multicert. When we try to match the client
connection, we match the SNI name first, then fall back to the IP address.

—
Reply to this email directly or view it on GitHub
#121 (comment).

[jpeach]

There's no such thing as a fallback; it's probably confusing to think of it in those terms. We index the certificate in order. In the case of name or address collisions, first certificate into the index is the winner. At lookup time, we search by SNI name, then by address. We always take the longs match, so an explicit name mapping beats a wildcard, and an address:port mapping beats an address mapping.

https://trafficserver.readthedocs.org/en/latest/reference/configuration/ssl_multicert.config.en.html#certificate-selection

[jacksontj]

Correct, and I'm just trying to say that if you have non sni clients its
first match wins (which it says). The second part is that the same
functionality is in reverse for * scopes (last match wins) for non sni
clients
On Sep 25, 2014 10:03 AM, "James Peach" notifications@github.com wrote:

There's no such thing as a fallback; it's probably confusing to think of
it in those terms. We index the certificate in order. In the case of name
or address collisions, first certificate into the index is the winner. At
lookup time, we search by SNI name, then by address. We always take the
longs match, so an explicit name mapping beats a wildcard, and an
address:port mapping beats an address mapping.

https://trafficserver.readthedocs.org/en/latest/reference/configuration/ssl_multicert.config.en.html#certificate-selection

—
Reply to this email directly or view it on GitHub
#121 (comment).

[jacksontj]

After talking with @jpeach it sounds like this isn't the case anymore. I'll verify what it does on master then update this PR. @jpeach has a patch which should fix this: http://fpaste.org/176424/22406097/

[jacksontj]

@jpeach Now that it's been fixed upstream, this covers what I was going for