OpenSSL возвращает другой SSL-сертификат, отличный от того, который показывает Chrome

При запросе URL-адреса CDN Sparkfun с использованием OpenSSL с помощью следующей команды:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

Общее имя, возвращаемое в сертификате *.sparkfun.com, не проверяется, но если вы загружаете хост в Chrome, отображается общее имя:*.cloudfront.net

Что здесь происходит?

Это вызывает проблему, потому что среда, в которой я нахожусь в прокси SSL через Squid SSL_Bump, генерирует сертификат, подписанный моим локально доверенным центром сертификации для домена. Это работает для всех доменов, но выше, так как CN не совпадает, поскольку новый сертификат генерируется с использованием OpenSSL.

РЕДАКТИРОВАТЬ - я убедился, что то же самое происходит с OpenSSL на сервере в удаленном центре обработки данных, который имеет прямое подключение к Интернету без прокси или фильтрации.

РЕДАКТИРОВАТЬ - Проблема связана с SNI, как принято, но для заполнения информации о том, почему это вызывает проблемы с Squid и SSL_Bump:

Этот проект не будет поддерживать пересылку информации с указанием имени сервера SSL (SNI) на исходный сервер и сделает такую ​​поддержку немного более сложной. Однако у пересылки SNI есть свои серьезные проблемы (выходящие за рамки этого документа), которые намного перевешивают дополнительные трудности пересылки.

Взято из: http://wiki.squid-cache.org/Features/BumpSslServerFirst

CloudFront использует SNI, способ использования нескольких сертификатов на одном IP. Все современные браузеры поддерживают это, как и команда openssl s_client, но s_client волшебным образом не делает этого. Вы должны сказать это, чтобы использовать это:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

Chrome поддерживает SNI , сообщая серверу, какой сертификат отправлять. Команда s_clientне делает.

Там больше деталей использования CloudFront о SNI здесь .

Когда вы используете SNI Custom SSL, некоторые пользователи могут не иметь доступа к вашему контенту, потому что некоторые старые браузеры не поддерживают SNI и не смогут установить соединение с CloudFront для загрузки HTTPS-версии вашего контента. Для получения дополнительной информации о SNI, включая список поддерживаемых браузеров, посетите страницу часто задаваемых вопросов .

и:

SNI Custom SSL опирается на расширение SNI протокола безопасности транспортного уровня, которое позволяет нескольким доменам обслуживать трафик SSL через один и тот же IP-адрес, в том числе пытаясь подключиться к ним с помощью средств просмотра имени хоста. Как и в случае специального выделенного IP-протокола IP, CloudFront доставляет контент из каждого периферийного местоположения Amazon CloudFront и обеспечивает ту же безопасность, что и функция специального выделенного IP-протокола IP. SNI Custom SSL работает с большинством современных браузеров, включая Chrome версии 6 и новее (работает на Windows XP и новее или OS X 10.5.7 и новее), Safari версии 3 и новее (работает на Windows Vista и новее или Mac OS X 10.5. 6. и более поздние версии), Firefox 2.0 и более поздние версии и Internet Explorer 7 и более поздние версии (работающие в Windows Vista и более поздних версиях). Старые браузеры, которые не поддерживают SNI, не могут установить соединение с CloudFront для загрузки HTTPS-версии вашего контента.