Better understanding TLS/SSL Alternative Names?

Question

Can someone explain (to a 5 year old) how Alternative Names are used? And why some domains have SO many?

Are all of these domains sharing a certificate? Are there any security risks (MitM attacks?) with using Alternative Names?

Answer 1

TLDR: That's Cloudflare

First, note that X.509 certificates can contain two different extensions, Subject Alternative Name(s) and Issuer Alternative Name(s). In practice no one uses IssuerAltNames, and the SSLLabs report you copied shows (only) SubjectAltNames, which practically everyone uses now and browsers have (just recently) begun to require.

The server using this certificate is part of CloudFlare's network. CloudFlare is (primarily) a so-called 'Content Delivery Network', which means they run webservers that initially handle WWW requests from browsers etc for lots of websites/domains owned by their customers. To quote their FAQ:

How does Cloudflare work?
Cloudflare protects and accelerates any website online. Once your website is a part of the Cloudflare community, its web traffic is routed through our intelligent global network. We automatically optimize the delivery of your web pages so your visitors get the fastest page load times and best performance. We also block threats and limit abusive bots and crawlers from wasting your bandwidth and server resources.

According to their homepage they currently handle 6 million 'properties' (presumably domains) using 115 datacenters worldwide. To do this they handle multiple domains on each server (otherwise they'd need more servers than anyone could afford), and the default certificate reflects this, although they offer dedicated certificates for an additional charge.

There is possible risk in using a shared server: if CloudFlare has a bug or makes a mistake it affects all the sites handled by the affected server(s), and there have been some cases of this (see the wikipedia article). However since their main business and full-time job is running these servers, the CloudFlare servers are probably better configured and monitored and more quickly patched when there is a problem than most (I'd guess at least 90%) of the origin servers run directly by domain owners.

There is no significant additional risk in using a shared certificate, since anyone looking at the DNS resolutions for the affected domains can already see they go via CloudFlare -- and all reasonably new software supports SAN, so the very few clients that have trouble connecting to a server using a SAN cert probably are pwned anyway. (Do not confuse this with the failure of slightly-less-ancient software like WindowsXP and early Android and Java6 (!) to support Server Name Indication aka SNI, a related but different feature of TLS.)

Note that even 'in-house' webservers may still use quite a few SubjectAltName entries in cases where a single enterprise owns and uses multiple domain names, such as:

• (non-wildcarded) subdomains like www.bigcorp.com sales.bigcorp.com support.bigcorp.com or
• same or similar names in different TLDs like www.bigcorp.co.uk www.bigcorp.co.jp or
• clearly different names like www.bigpreviousname.com www.bigbrandslogan.com etc.

Answer 2

Before we had the Subject Alternative Name (SAN) extension, certificates could only have a single "common name". This common name was used by a client to validate that the service they are talking to is the service they expected to be talking to and not a malicious, fake, or misconfigured service.

For websites in particular, many sites like to have multiple possible names that clients can use to connect with (www.example.com, example.com, example.net, www.example.co.uk, example.tv). But it was a burden to obtain a certificate for each possible name. Additionally, earlier versions of the SSL and TLS protocols required that each certificate be hosted on a unique IP/port combination which added additional cost and configuration effort.

The SAN extension allows for multiple additional identifiers (not just DNS names) to be associated with a single certificate. This is a huge time and cost saver for both problems mentioned above. A single site with multiple names could now use a single certificate containing all the names with a single IP/port combination on the web server.

SAN certificates can also be useful even for different sites sitting behind a common load balancer or reverse proxy that is terminating the TLS connection. This is common in a Content Delivery Network (CDN) like CloudFlare or Akamai. This is also why you may find certificates in the wild with a lot of seemingly unrelated SAN entries.

In answer to your other questions:

Are all of these domains sharing a certificate?

Yes

Are there any security risks (MitM attacks?) with using Alternative Names?

There no specific security risks with using SAN certificates. They're just as trustworthy as non-SAN certificates. However, it could be argued that you have the normal risks associated with putting "many eggs in one basket". A problem with that cert affects all of the sites using it.