We run a store frontend with 15 different wildcard domains (*.foo.ie, *.foo.uk etc) in the certificate. We're considering adding the root domain (foo.ie, foo.uk) into the certificate, to let the store frontend handle the redirect to www.foo.* - or possibly set up another certificate with just the root certificates, and a simple frontend that just redirects it.

My question is, does a certificate with many domain names cause increased HTTPS negotiation times by any significant factor - ie, by causing more data to be sent over the wire, possibly causing more TCP segments?

There's added cost in reading the cert from disk/ram and processing it, but this should be negligible compared to even minor increases in 'time on the wire'.

  • Did you notice the massive lag on *.stackexchange.com cert? ... no? Me neither ... and stack exchange has hundreds of subdomains on that wildcard. Commented Jan 18, 2018 at 14:19
  • How many names they have in DNS is hardly relevant; the wildcard certificate *.stackexchange.com is still just one line of text and would actually be a little less than the average certificate (The cert has 25 alternate domains, however, which makes it closer to our use case) To clarify the question a bit: in the context of a single transaction, the time to negotiate TLS is hardly noticeable, but if you're hosting a large site and the time a client stays connected on average increases by 10%, it can have a noticeable effect on the resources you need to allocate to the frontend servers.
    – rln
    Commented Jan 19, 2018 at 12:59

2 Answers 2


The number of names is a very small amount of data overall; if it pushes delivering the certificate over a packet size threshold, the added delay won't perceptibly impact human users that have broadband or other high speed connections. The receiving computer will have up to 14 extra strings to scan; again, an imperceptible amount of overhead to any particular human user.

Qualys SSL Labs did a certificate survey a few years ago, and presented their findings at Blackhat. They found many issues that contributed to performance problems. In the case of multiple domain names, they found one certificate with 354 unrelated domain names, and the certificate was 8.2KB long! So yes, there is a line you probably don't want to cross, and 354 appears to cross it.

Another common problem they found impacting performance was that some validation chains were too long. A long time ago, some PKI architects were advocating a multi-tiered approach, where every certificate would be signed by a root CA, one or two Subordinate CAs, and one or two Policy CAs. Running through the RSA math on four different validation steps is what bogged down the clients, much more than the size of the certificates. (Qualys found 8 certificates that had a signing depth of 6!) To keep performance as high as possible, keep the signing chain as short as possible.

They also saw 43% of servers were sending too many certificates. Normally, you would include the server's cert and any intermediate signing certificates needed to validate it up to the root (the root cert is normally contained within the browser, unless it's a self-signed cert.) Many sites were wasting bandwidth by including additional certificates not needed to validate their site. One site sent a certificate file back that contained 116 certificates!

Finally, they found lots of certificates that were just plain bad. They were self-signed, expired, used weak algorithms, or had other flaws that meant their protection was less than optimal. Of all the things you need to achieve with a certificate, security is number one - performance is not. So I'd recommend using their analysis tool and finding out what they think of your setup. https://www.ssllabs.com/ssltest/index.html . I run this check every time I change my server's configuration and after updating my certificate.

UPDATE: I've switched to using an nmap script to check my server. Make sure you're running an up-to-date version of nmap, then run nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org. This will list the ciphers supported by the server, and provide a letter grade indicating the security of each, and an overall grade for your server. Good for finding things like out of date and insecure versions of SSL/TLS, 64 bit ciphers, etc. And you can run it on any host and port, so you can test app servers, web services, internal servers that are behind your firewalls, etc.


Since all the subject alternative names are part of the certificate and the certificate is sent by the server with each full SSL handshake more data will be sent over the wire if you have more names in the certificate. In the worst case this might result in additional packets needed or even that the full server response exceeds the initial window in TCP and thus will be delayed until the client has acknowledged the previous data. This is especially true on older systems with a low initial window size and if multiple intermediate certificates are needed and large key sizes are used which all add to the size of the response.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .