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

TLDR: это Cloudflare

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

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

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

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

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

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

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

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

До того, как у нас было расширение Subject Alternative Name (SAN), сертификаты могли иметь только одно "общее имя". Это общее имя использовалось клиентом для проверки того, что служба, с которой он общается, является службой, с которой он ожидал общаться, а не с вредоносной, поддельной или неправильно настроенной службой.

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

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

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

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

Все ли эти домены имеют общий сертификат?

да

Существуют ли угрозы безопасности (атаки MitM?) При использовании альтернативных имен?

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