Лучше понимать альтернативные имена TLS / SSL?

TL; DR: это Cloudflare

Во-первых, обратите внимание, что сертификаты X.509 могут содержать два разных расширения, Тема Альтернативное имя (я) и альтернативное имя (я) эмитента. На практике никто не использует IssuerAltNames, и отчет SSLLabs, который вы скопировали, показывает (только) SubjectAltNames, который практически все используют сейчас, а браузеры (совсем недавно) начали требовать.

Сервер, использующий этот сертификат, является частью сети CloudFlare. CloudFlare является (в первую очередь) так называемой «сетью доставки контента», что означает, что они запускают веб-серверы, которые изначально обрабатывают запросы WWW от браузеров и т. д. для лоты веб-сайтов / доменов, принадлежащих их клиентам. Процитирую их FAQ:

Как работает Cloudflare?
Cloudflare защищает и ускоряет работу любого веб-сайта в Интернете. Когда ваш веб-сайт становится частью сообщества Cloudflare, его веб-трафик направляется через нашу интеллектуальную глобальную сеть. Мы автоматически оптимизируем доставку ваших веб-страниц, чтобы ваши посетители получали максимальную скорость загрузки страниц и лучшую производительность. Мы также блокируем угрозы и ограничиваем использование злоумышленниками ботов и сканеров, которые тратят вашу пропускную способность и ресурсы сервера.

Согласно их домашней странице, в настоящее время они обрабатывают 6 миллионов «объектов» (предположительно доменов) в 115 центрах обработки данных по всему миру. Для этого они обрабатывают несколько доменов на каждом сервере (в противном случае им потребуется больше серверов, чем кто-либо может себе позволить), и сертификат по умолчанию отражает это, хотя они предлагают специальные сертификаты за дополнительную плату.

Существует возможный риск при использовании общего сервера: если CloudFlare имеет ошибку или делает ошибку, это влияет на все сайты, обрабатываемые затронутыми серверами, и в некоторых случаях это было (см. Статью в википедии). Однако, поскольку их основная деятельность и постоянная работа связаны с этими серверами, серверы CloudFlare, вероятно, лучше настраиваются, контролируются и быстрее исправляются при возникновении проблемы, чем большинство (я предполагаю, что не менее 90%) исходных серверов работают. непосредственно владельцами доменов.

Нет значительного дополнительного риска при использовании общего сертификата, поскольку любой, кто просматривает разрешения DNS для затронутых доменов, уже может видеть, что они проходят через CloudFlare - и все достаточно новое программное обеспечение поддерживает SAN, поэтому очень немногие клиенты, у которых возникают проблемы с подключением к сервер, использующий сертификат SAN, вероятно, в любом случае захвачен. (Не путайте это с неспособностью немного менее древнего программного обеспечения, такого как WindowsXP и ранние версии Android и Java6 (!), Поддерживать указание имени сервера, также известное как SNI, родственная, но другая функция TLS.)

Обратите внимание, что даже «внутренние» веб-серверы могут по-прежнему использовать довольно много записей SubjectAltName в тех случаях, когда одно предприятие владеет и использует несколько доменных имен, например:

• (без подстановочных знаков) поддомены, такие как www.bigcorp.com sales.bigcorp.com support.bigcorp.com или
• одинаковые или похожие имена в разных TLD, таких как www.bigcorp.co.uk, www.bigcorp.co.jp или
• явно разные имена, такие как www.bigpreviousname.com, www.bigbrandslogan.com и т. д.

Раньше у нас был Альтернативное имя субъекта (SAN), сертификаты могут иметь только одно «общее имя». Это общее имя использовалось клиентом для подтверждать что служба, с которой они разговаривают, является службой, с которой они, как они ожидали, будут разговаривать, а не злонамеренной, поддельной или неправильно настроенной службой.

В частности, для веб-сайтов многим сайтам нравится иметь несколько возможных имен, которые клиенты могут использовать для подключения (www.example.com, example.com, example.net, www.example.co.uk, example.tv). Но получить сертификат на каждое возможное имя было обузой. Кроме того, более ранние версии протоколов SSL и TLS требовали, чтобы каждый сертификат размещался на уникальной комбинации IP / порта, что добавляло дополнительных затрат и усилий по настройке.

Расширение SAN позволяет связать несколько дополнительных идентификаторов (а не только DNS-имена) с одним сертификатом. Это огромная экономия времени и средств для решения обеих проблем, упомянутых выше. Один сайт с несколькими именами теперь может использовать один сертификат, содержащий все имена с одной комбинацией IP / порта на веб-сервере.

Сертификаты SAN также могут быть полезны даже для разных сайтов, находящихся за общим балансировщиком нагрузки или обратным прокси-сервером, который завершает соединение TLS. Это обычное дело в Сеть доставки контента (CDN) нравится CloudFlare или Акамай. Вот почему вы можете найти сертификаты в «дикой природе» с множеством, казалось бы, не связанных записей SAN.

Отвечая на другие ваши вопросы:

Все ли эти домены используют сертификат?

да

Есть ли риски безопасности (атаки MitM?) С использованием альтернативных имен?

Нет конкретных безопасность риски при использовании сертификатов SAN. Они так же надежны, как и сертификаты, не относящиеся к SAN. Однако можно возразить, что у вас есть обычные риски, связанные с тем, что кладете «много яиц в одну корзину». Проблема с этим сертификатом затрагивает все сайты, которые его используют.