
При запросе URL-адреса CDN Sparkfun с использованием OpenSSL с помощью следующей команды:
openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443
Общее имя, возвращаемое в сертификате *.sparkfun.com
, — , которое не проходит проверку, но если вы загрузите хост в Chrome, то отобразится общее имя*.cloudfront.net
Что здесь происходит?
Это вызывает проблему, поскольку среда, в которой я нахожусь, проксирует SSL через Squid SSL_Bump, который генерирует сертификат, подписанный моим локально доверенным CA для домена. Это работает для всех доменов, кроме указанных выше, поскольку CN не совпадает, поскольку новый сертификат генерируется с помощью OpenSSL.
РЕДАКТИРОВАТЬ- Я убедился, что то же самое происходит с OpenSSL на сервере в удаленном центре обработки данных, который имеет прямое подключение к Интернету без использования прокси-серверов или фильтрации.
РЕДАКТИРОВАТЬ- Проблема связана с SNI, как принято, но для заполнения информации о том, почему она вызывает проблемы со Squid и SSL_Bump:
Этот проект не будет поддерживать пересылку информации SSL Server Name Indication (SNI) на исходный сервер и немного затруднит такую поддержку. Однако пересылка SNI имеет свои собственные серьезные проблемы (выходящие за рамки этого документа), которые намного перевешивают дополнительные трудности пересылки.
Взято из:http://wiki.squid-cache.org/Features/BumpSslServerFirst
решение1
CloudFront использует SNI, способ использования нескольких сертификатов на одном IP. Все современные браузеры поддерживают это, как и команда s_client openssl, но s_client не делает этого магическим образом. Вам нужно указать ему, чтобы он использовал это:
openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts
решение2
Chrome поддерживаетСНИ, сообщая серверу, какой сертификат отправить. s_client
Команда этого не делает.
Более подробная информация об использовании SNI компанией CloudFrontздесь.
При использовании SNI Custom SSL некоторые пользователи могут не иметь доступа к вашему контенту, поскольку некоторые старые браузеры не поддерживают SNI и не смогут установить соединение с CloudFront для загрузки HTTPS-версии вашего контента. Для получения дополнительной информации о SNI, включая список поддерживаемых браузеров, посетите нашЧасто задаваемые вопросыстраница.
и:
SNI Custom SSL использует расширение SNI протокола Transport Layer Security, которое позволяет нескольким доменам обслуживать трафик SSL по одному IP-адресу, включая имя хоста, к которому пытаются подключиться зрители. Как и в случае с выделенным IP Custom SSL, CloudFront доставляет контент из каждого периферийного местоположения Amazon CloudFront с той же безопасностью, что и функция выделенного IP Custom SSL. 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-версии вашего контента. SNI Custom SSL доступен без дополнительных затрат, помимо стандартных сборов за передачу и запрос данных CloudFront.