При запросе 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 Server Name Indication (SNI) на исходный сервер и сделает такую поддержку немного более сложной. Однако пересылка SNI имеет свои собственные серьезные проблемы (выходящие за рамки этого документа), которые намного перевешивают дополнительные трудности пересылки.
Взято из: http://wiki.squid-cache.org/Features/BumpSslServerFirst
CloudFront использует SNI, способ использования нескольких сертификатов на одном IP. Все современные браузеры поддерживают это, как и команда s_client openssl, но s_client не делает этого волшебным образом. Вы должны сказать ему, чтобы использовать его:
openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts
Chrome поддерживает SNI, сообщая серверу, какой сертификат отправить. В s_client команда не работает.
Более подробная информация об использовании SNI в CloudFront Вот.
Когда вы используете SNI Custom SSL, некоторые пользователи могут не иметь доступа к вашему контенту, потому что некоторые старые браузеры не поддерживают SNI и не смогут установить соединение с CloudFront для загрузки HTTPS-версии вашего контента. Для получения дополнительной информации о SNI, включая список поддерживаемых браузеров, посетите наш Вопросы-Ответы страница.
и:
SNI Custom SSL основывается на расширении SNI протокола Transport Layer Security, которое позволяет нескольким доменам обслуживать трафик SSL по одному и тому же IP-адресу, включая средства просмотра имен хостов, к которым пытаются подключиться. Как и в случае с настраиваемым SSL для выделенного IP-адреса, CloudFront доставляет контент из каждого пограничного местоположения Amazon CloudFront с той же безопасностью, что и функция настраиваемого SSL для выделенного 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-версии вашего контента. Пользовательский SSL SNI доступен без дополнительных затрат, помимо стандартной платы за передачу данных CloudFront и плату за запросы.