>> Is there any limitation to the number of Subject Alternate Names in a
>> certificate that TrafficServer can use to secure HTTPS responses?
>>Is a SAN/UCC cert with 250+ SANs supported?
> Yep, there’s no enforced limits. It should be easy to verify that this works.
FWIW, while X509v3 doesn't define a limit (RFC5280), many CA's do have a limit
which 250+ may be beyond. For example, Symantec has a limit of 100. DigiCert
limit is 25.
Dave
On Wednesday, April 6, 2016 10:27 PM, James Peach <[email protected]> wrote:
> On Apr 6, 2016, at 7:28 PM, Eric Friedrich (efriedri) <[email protected]>
> wrote:
>
> Is there any limitation to the number of Subject Alternate Names in a
> certificate that TrafficServer can use to secure HTTPS responses?
>
> Is a SAN/UCC cert with 250+ SANs supported?
Yep, there’s no enforced limits. It should be easy to verify that this works.
> Would the certificate resolution process be substantially slowed down by the
> large number of alternate names?
No, I would not expect so. It’s a hash lookup on the SNI name provided by the
client, so it’s relatively insensitive to the number of alternate names.
> Does ATS cache result of certificate resolution process to speed it up for
> future requests?
No. There’s no real resolution process to cache. We look up a certificate match
by SNI name (preferred) and fall back to the destination IP address if we have
to. The cost is constant (up to 2 hash lookups, and a trie longest match if you
have wildcards).
J
