wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Sni ssl: Настраиваем HTTPS-сервер на nginx / Хабр

alexxlab
No Comments

Содержание

Настраиваем HTTPS-сервер на nginx / Хабр

Для чего я это пишу?

В последнее время в связи с кучей факторов (АНБ, DPI с рекламой и другое) у меня начала просыпаться паранойя и я подумал полностью перевести свой небольшой сайт на https. На хабре было несколько статей с техническими подробностями работы SSL/TLS, однако поискав информацию на тему настройки https-вебсервера обнаружил традиционное деление статей — либо это статьи «Делайте вот так», где просто даны настройки без каких-либо разъяснений и вариантов использования, либо это большие теоретические статьи, где обсуждаются различные схемы использования, но без практически применимых готовых вариантов. На хабре была статья о настройке, однако в ней нет информации про DH-кодировки, да и некоторые параметры не описаны. Подумал, что стоит упорядочить найденное в виде статьи, которая будет полезна тем, кто хотел бы развернуть https у себя на сервере, но не слишком углубляться в дебри SSL.

Повествование будет вестись с учетом того, что веб-сервером выступает nginx (и в одном месте будет параметр для php-fpm).

Сертификат

У меня уже был сертификат от StartSSL. О нем уже писали на хабре, так что на этом шаге задерживаться не буду. Скажу только, что в течении первых двух-трех дней браузеры, проверяющие сертификат на сервере, могут на него ругаться (у меня такое происходило с Opera 12 и Firefox), видимо у StartCom кеши валидных сертификатов обновляются не так часто. Про установку же будет сказано ниже

О вариантах настройки

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

В общем случае есть два актуальных на данный момент варианта настройки — с Forward Secrecy и без него. При настройке различие только в наборе кодировок (директива ssl_ciphers), однако тут стоит задуматься, что же вы хотите от https.

О Forward Secrecy можно почитать скажем тут. В двух словах, суть заключается в том, что для актуального на данный момент алгоритма RC4 ключи сессии генерируются на основе приватного ключа сервера. Таким образом, если приватный ключ будет скомпрометирован, появится возможность расшифровать все сессии (если они были записаны). В случае же использования DH-кодировок, каждая сессия имеет свой набор ключей, которые сессии никак не зависят от приватного ключа. Однако в этом случае тратится гораздо больше процессорного времени на хендшейк, что увеличивает нагрузку и время открытия страницы.

Тут стоит задуматься, для чего нужен https конкретно у вас на сайте. При большом количестве посетителей использование DH-алгоритмов шифрования может прилично увеличить нагрузку (которая в любом случае повысится при переходе на HTTPS), в некоторых случаях придется увеличить тариф на VDS и т.п. В большинстве случаев RC4 достаточно, однако многим хочется чтобы все было «по высшему классу», так почему бы не сделать, если ресурсы позволяют?

Настройка nginx

В результате настройки у меня сформировался приблизительно такой конфиг, суть параметров поясню ниже.

В секции http необходимо добавить:

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_stapling on;
resolver 8.8.8.8;

Секция server же получится приблизительно такая:

server {
    listen       443 ssl;
    server_name  www.site.ru;
    .......

    keepalive_timeout   60;
    ssl_certificate      certificate_bundled.crt;
    ssl_certificate_key  privatekey.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers  "HIGH:!RC4:!aNULL:!MD5:!kEDH";
    add_header Strict-Transport-Security 'max-age=604800';

	.......
    location ~ \.php$ {
	.......
        fastcgi_param HTTPS on; # Для php-fpm
	.......
    }
}

В данном примере не используются DH-алгоритмы, т.е. нет Forward Secrecy. Из улучшений тут можно опустить поддержку SSLv3 (убрав его из ssl_ciphers), таким образом перестанет поддерживаться IE 6 и ниже, поскольку он не поддерживает TLS, а так же увеличить время STS, но об этом ниже.

Без SSLv3 такая настройка дает оценку 100-95-100-90 в тесте SSL.

Пройдемся по параметрам

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 5m;
«Задаёт тип и размеры кэшей для хранения параметров сессий.» (nginx.org) Кеш необходим для возможности повторного использования ключей сессии, таким образом при установлении нового соединения будут использоваться старые ключи, т.е. не будет повторно производиться хендшейк. Особенно актуально при использовании кодировки DHE (например в бразуере Opera 12), поскольку время загрузки страницы со всеми элементами сильно увеличивается при отсутствии кеша, а DHE еще и использует больше ресурсов и времени (относительно EECDH и RC4). Параметр shared задает общий для всех рабочих процессов nginx кеш, 10m — объем кеша (10 МБ, при этом 1 МБ~4000 сессий, таким образом при этих настройках можно хранить до 40 тысяч сессий), 5m — таймаут сессии в кеше (5 минут).

ssl_prefer_server_ciphers on;

«Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские.» (nginx.org) — клиентские шифры (CBC) уязвимы к некоторым типам атак.

ssl_stapling on;

Позволяет серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. ЗДесь имеются ввиду ответы о валидности сертификата (при проверке на отозванность). С точки зрения безопасности пользователя не важно, кто передает ответы — веб-сервер или сервер CA — ведь ответ в любом случае подписан и валидность ответа тоже можно проверить, а ответ включает в себя свой срок действия.

Для работы этой функции нужно указать DNS-сервер, что и делается директивой resolver.

keepalive_timeout — думаю в описании не нуждается, не стоит выключать или ставить слишком малым для уменьшения нагрузки из-за повторного установления соединения.

ssl_certificate и ssl_certificate_key указывают на файл сертфиката и файл приватного ключа для него. Так как я рассказываю на примере сертификата от StartSSL, то здесь допущу небольшой комментарий относительно инструкций StartSSL по установке сертификата — не нужно добавлять сертификат Root CA в обобщенный файл сертификата, поскольку это не имеет смысла и только увеличивает, хоть и не на много, размер передаваемых данных. Достаточно иметь в файле последовательно личный сертификат и сертификат промежуточного центра сертификации. Готовый файл сертификата для nginx (для сетификата StartSSL) можно получить следующей командой:

cat certificate.crt sub.class1.server.ca.pem > certificate_bundled.crt

Где ваш сертификат — certificate.crt, а промежуточный сертификат — www.startssl.com/certs/sub.class1.server.ca.pem

add_header Strict-Transport-Security ‘max-age=604800’;

Strict-Transport-Secutiry — заголовок, указывающий браузеру на то, что сайт доступен только по https. Это предотвращает возможность перехода обратно на http-версию для последующей атаки через незашифрованное соединение. Кстати данный параметр еще удобен тем, что при наличии в коде страницы «забытого» подключения ресурса (картинки/скрипта/стиля/…) с того же сайта по http, браузер сам пойдет на https-версию и не будет ругаться на частично незашифрованное соединение. Конечно же это не сработает для внешних ресурсов. Время — неделя. Многие рекомендуют ставить 1 год, однако в случае решения в будущем отказаться от использования https это может доставить проблемы некоторым пользователям. Время обновляется при каждой передаче этого заголовка, т.е. при каждом заходе на сайт.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Указывает поддерживаемые протоколы. SSLv2 и v3 имеют критические уязвимости.

ssl_ciphers «HIGH:!RC4:!aNULL:!MD5:!kEDH»;

Указывает используемые шифры. Собственно за счет изменения набора шифров и настраивается Forward Secrecy. От стандартного набора, предлагаемого nginx, отличается только параметром !kEDH,

Forward Secrecy

Для включения Forward Secrecy можно использовать например такой набор шифров:

ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

Кроме того, необходимо настроить приоритет шифров OpenSSL:

openssl ciphers -V 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA256 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

В данном варианте не запрещается использование RC4 для сохранения совместимости с некоторыми браузерами, однако не так давно обнаружились уязвимости и в нем, хоть и практически трудно реализуемые.

Для усиления шифрования можно увеличить стойкость DH-шифров, создав файл параметров DH-шифров (создание файла займет некоторое время!), скажем длинной 4096 бит:

openssl dhparam -out dh5096.pem 4096

И добавив в конфиг nginx директиву

ssl_dhparam dh5096.pem;

Это можно делать для скажем для веб-интерфейсов управления сервером/службами, однако хендшейк будет происходить еще дольше, поэтому не стоит делать это на обычном сайте.

Про CDN-сервисы

В обсуждении инструкций по настройке Forward Secrecy было замечено, что по крайней мере CDN Amazon CloudFront не поддерживает обмен с вашим сервером в DH-кодировках, да и RC4 вроде тоже, что не радует. Возможно что и с другими CDN тоже не все идеально, но я лично пока с ними не сталкивался, поэтому ничего сказать не могу.

Полезные ссылки

Тестирование настроек https-вебсервера
Настройки Apache и nginx для Forward Secrecy

Как проверить, использует ли ваш браузер технологии Secure DNS, DNSSEC, TLS 1.3 и Encrypted SNI

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

Большинство современных браузеров располагают встроенными функциями обеспечения дополнительной безопасности, но далеко не во всех обозревателях они включены по умолчанию. К примеру, чтобы повысить уровень безопасности в популярном браузере Firefox, в скрытых настройках нужно включить неактивные по умолчанию защищенный DNS и шифрованный SNI. С другими браузерами дела обстоят не так хорошо, для повышения уровня безопасности в них приходится прибегать к сторонним расширениям или лезть в настройки ОС.

Проверить, используются ли специальные фишки безопасности в вашем браузере очень просто, достаточно пройти тест в онлайновом сервисе Browsing Experience Security Check.

Зайдите на страницу www.cloudflare.com/ssl/encrypted-sni и нажмите кнопку «Check my browser». Тест покажет, использует ли веб-обозреватель технологии Secure DNS, DNSSEC, TLS 1.3 и Encrypted SNI.

Пару слов о том, что представляет собой каждая из этих технологий.

• Secure DNS — технология шифрования DNS-запросов, обеспечивает повышенную безопасность передачи данных посредством шифрования с использованием стандартов DNS-over-TLS или DNS-over-HTTPS.

• DNSSEC — выполняет проверку подлинности DNS-запросов, использует криптографию с открытым ключом, позволяет минимизировать атаки, связанные с подменой адресов DNS.

• TLS 1.3 — последняя на данный момент версия протокола защиты транспортного уровня, служащего для защиты данных, передаваемых между узлами в интернете. Для обеспечения повышенной безопасности протокол использует симметричное и асимметричное шифрование.

• Encrypted SNI — специальная технология шифрования, в задачи которой входят предотвращение получения сторонними наблюдателями информации о соединении.

Что делать, если тест пройден лишь частично?

Если конфиденциальность в интернете стоит у вас на первом месте, используйте Firefox, который поддерживает и Secure DNS, и Encrypted SNI (пока в тестовом режиме).

Чтобы включить эти функции, перейдите на страницу флагов about:config, найдите через поиск настройку network.security.esni.enabled и измените ее значение с false на true.

Затем найдите настройку network.trr.mode и установите в качестве ее значения 2.

Наконец, отыщите настройку network.trr.uri и убедитесь, что в качестве ее значения установлен адрес https://mozilla.cloudflare-dns.com/dns-query.

После внесения этих изменений, все четыре теста должны быть пройдены успешно.

Означает ли это, что повышенная безопасность будет обеспечена на всех сайтах, которые вы посещаете? Увы, нет. Важно, чтобы посещаемый вами ресурс тоже поддерживал DNSSEC, TLS 1.3 и Encrypted SNI, в противном случае потенциальная угроза безопасности по-прежнему будет сохраняться.

⏫ Проверьте, использует ли ваш браузер Secure DNS, DNSSEC, TLS 1.3 и зашифрованный SNI – Information Security Squad

Cloudflare Browsing Experience – онлайн-инструмент, который проверяет возможности веб-браузера в отношении определенных функций, связанных с конфиденциальностью и безопасностью.

Для некоторых пользователей Интернета конфиденциальность имеет первостепенное значение.

Хотя большинству это кажется безразличным, некоторые стараются изо всех сил внедрить защитные механизмы, чтобы устранить или, по крайней мере, уменьшить то, что компании и, возможно, даже государственные субъекты могут узнать о них, когда они используют Интернет.

Успешно это или нет, зависит от программы, используемой для подключения к интернет-сайтам, например, браузер или медиа-клиент, а также конфигурация системы.

Толчок к использованию HTTPS в Интернете обеспечил шифрование большей части данных, передаваемых между браузером или программой пользователя и сайтами в Интернете.

Новые технологии, такие как Secure DNS или собственная зашифрованная индикация имени сервера (SNI) Cloudflare, предназначены для устранения утечек, вызванных DNS-запросами.

Проверка безопасности просмотра веб-страниц

Browsing Experience Security Check  проверяет возможности веб-браузера в отношении функций безопасности и конфиденциальности.

Примечание: тест поддерживается Cloudflare; Компания разработала Зашифрованный SNI, который проверяет и этот момент среди прочего.

Тест прост: подключитесь к тестовой странице с помощью браузера и нажмите кнопку Check My Browser на странице, чтобы запустить тест.

Он проверяет, включены ли Secure DNS, DNSSEC, TLS 1.3 и Encrypted SNI. Вот краткое описание каждой функции:

  • Secure DNS  – технология, которая шифрует запросы DNS, например, поиск ghacks.net для получения IP-адреса. Два стандарта, DNS-over-TLS или DNS-over-HTTPS, подпадают под категорию.
  • DNSSEC – предназначен для проверки подлинности DNS-запросов.
  • TLS 1.3 – последняя версия протокола TLS, которая имеет множество улучшений по сравнению с предыдущими версиями.
  • Encrypted SNI – Индикация имени сервера, короткий SNI, показывает имя хоста во время соединений TLS. Любой, кто слушает сетевой трафик, например Интернет-провайдеры или организации могут регистрировать посещенные сайты, даже если используются TLS и Secure DNS. Зашифрованный SNI шифрует биты, так что только IP-адрес все еще может быть подвержен раскрытию.

Единственный браузер, который поддерживает все четыре функции в то время, – это Firefox.

Вот краткий список инструкций по настройке Безопасного DNS и Зашифрованного SNI в Firefox:

  • Впишите about:config в адресную строку Firefox.
  • Подтвердите, что вы будете осторожны.
    Зашифрованный SNI: найдите network.security.esni.enabled и установите значение True
    Защищенный DNS: найдите network.trr.mode и установите для него значение 2. Найдите network.trr.uri и установите для него значение https://mozilla.cloudflare-dns.com/dns-query.

Обратите внимание, что Secure DNS поддерживает другие серверы, если вы не хотите использовать Cloudflare

Теперь вы: Какие расширения или настройки конфиденциальности и безопасности вы используете в своем браузере?

Настройка серверов HTTPS

Настройка серверов HTTPS

Для настройки HTTPS-сервера параметр ssl
должен быть включен
гнезда для прослушивания
в серверном блоке,
и расположение
сертификат сервера
а также
закрытый ключ
файлы должны быть указаны:

server {
    слушайте 443  ssl ;
    имя_сервера www.example.com;
    ssl_certificate  www.example.com.crt ;
    ssl_certificate_key  www.example.com.key ;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:! aNULL:! MD5;
    ...
}

Сертификат сервера является публичным.
Он отправляется каждому клиенту, который подключается к серверу.
Закрытый ключ является защищенным объектом и должен храниться в файле с
ограниченный доступ, однако он должен быть доступен для чтения главным процессом nginx.
В качестве альтернативы закрытый ключ может храниться в том же файле, что и сертификат:

    ssl_certificate www.example.com.cert;
    ssl_certificate_key www.example.com.cert;

в этом случае права доступа к файлу также должны быть ограничены.
Хотя сертификат и ключ хранятся в одном файле,
клиенту отправляется только сертификат.

Директивы ssl_protocols и
ssl_ciphers
может использоваться для ограничения подключений
включать только сильные версии и шифры SSL / TLS.
По умолчанию nginx использует
« ssl_protocols TLSv1 TLSv1.1 TLSv1.2 »
и « ssl_ciphers HIGH:! aNULL:! MD5 »,
поэтому их явная настройка обычно не требуется.Обратите внимание, что значения по умолчанию для этих директив были
менял несколько раз.

Оптимизация HTTPS-сервера

Операции SSL потребляют дополнительные ресурсы ЦП.
В многопроцессорных системах несколько
рабочие процессы
должен быть запущен,
не меньше количества доступных ядер процессора.
Самой интенсивной операцией с использованием ЦП является квитирование SSL.
Есть два способа минимизировать количество этих операций на одного клиента:
во-первых, путем включения
поддерживать активность
соединений для отправки нескольких
запросы через одно соединение, а второе — повторно использовать сеанс SSL
параметры, чтобы избежать подтверждения SSL для параллельных и последующих подключений.Сеансы хранятся в кэше сеансов SSL, совместно используемом работниками.
и настроен
ssl_session_cache
директива.
Один мегабайт кеша содержит около 4000 сессий.
Тайм-аут кеширования по умолчанию составляет 5 минут.
Его можно увеличить, используя
ssl_session_timeout
директива.
Вот пример конфигурации, оптимизированной для многоядерной системы.
с общим кешем сеанса 10 мегабайт:

  worker_processes auto ;

http {
      ssl_session_cache общий: SSL: 10 м ;
      ssl_session_timeout 10m ;

    server {
        слушайте 443 ssl;
        имя_сервера www.example.com;
          keepalive_timeout 70 ;

        ssl_certificate www.example.com.crt;
        ssl_certificate_key www.example.com.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers HIGH:! aNULL:! MD5;
        ...
Цепочки сертификатов SSL

Некоторые браузеры могут жаловаться на сертификат, подписанный известным
центр сертификации, в то время как другие браузеры могут принимать сертификат
без проблем.
Это происходит из-за того, что выдающий орган подписал сертификат сервера.
с использованием промежуточного сертификата, которого нет в сертификате
база известных доверенных центров сертификации, которая распространяется
с конкретным браузером.В этом случае орган предоставляет набор связанных сертификатов.
который должен быть присоединен к подписанному сертификату сервера.
Сертификат сервера должен располагаться перед связанными сертификатами.
в объединенном файле:

$ cat www.example.com.crt bundle.crt> www.example.com.chained.crt

Полученный файл следует использовать в
Директива ssl_certificate:

server {
    слушайте 443 ssl;
    имя_сервера www.example.com;
    ssl_certificate www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

Если сертификат сервера и пакет были неправильно объединены
order, nginx не запустится и отобразит сообщение об ошибке:

SSL_CTX_use_PrivateKey_file ("... /www.example.com.key") не удалось
   (SSL: ошибка: 0B080074: процедуры сертификата x509:
    X509_check_private_key: несоответствие значений ключей)

потому что nginx пытался использовать закрытый ключ с пакетом
первый сертификат вместо сертификата сервера.

Браузеры обычно хранят промежуточные сертификаты, которые они получают.
и которые подписаны доверенными органами, поэтому активно используемые браузеры
может уже иметь необходимые промежуточные сертификаты и
не может жаловаться на сертификат, отправленный без связанного пакета.
Чтобы сервер отправил полную цепочку сертификатов,
Можно использовать утилиту командной строки openssl , например:

$ openssl s_client -connect www.godaddy.com:443
...
Цепочка сертификатов
 0 с: / C = США / ST = Аризона / L = Скоттсдейл / 1.3.6.1.4.1.311.60.2.1.3 = США
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     / OU = MIS Department /  CN = www.GoDaddy.com 
     /serialNumber=0796928-7/2.5.4.15=V1.0, пункт 5. (b)
   i: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     / CN = Центр сертификации Go Daddy Secure
     / serialNumber = 07969287
 1 с: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     / CN = Центр сертификации Go Daddy Secure
     / serialNumber = 07969287
   i: / C = US / O = The Go Daddy Group, Inc./ OU = Центр сертификации Go Daddy Class 2
 2 с: / C = US / O = The Go Daddy Group, Inc.
     / OU = Центр сертификации Go Daddy Class 2
   i: / L = Сеть валидации ValiCert / O =  ValiCert, Inc. 
     / OU = Центр проверки политик ValiCert класса 2
     /CN=http://www.valicert.com//[email protected]
...

При тестировании конфигураций с SNI,
важно указать опцию -servername
поскольку openssl не использует SNI по умолчанию.

В этом примере субъект (« s »)
www.GoDaddy.com сертификат сервера № 0 подписан эмитентом
(« i »), который сам является предметом сертификата № 1,
который подписан эмитентом, который сам является субъектом сертификата № 2,
который подписан известным эмитентом ValiCert, Inc.
чей сертификат хранится во встроенной в браузере
база сертификатов (которая лежала в доме, построенном Джеком).

Если пакет сертификатов не был добавлен, только сертификат сервера № 0
будет показано.

Один сервер HTTP / HTTPS

Можно настроить один сервер, который обрабатывает как HTTP
и HTTPS-запросы:

server {
    слушать 80;
    слушайте 443 ssl;
    имя_сервера www.example.com;
    ssl_certificate www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ...
}

До версии 0.7.14 SSL нельзя было включить выборочно для
отдельные гнезда для прослушивания, как показано выше.SSL можно было включить только для всего сервера с помощью
директива ssl,
что делает невозможным установку единого HTTP / HTTPS-сервера.
Параметр ssl
директива слушать
был добавлен для решения этой проблемы.
Использование
ssl директива
в современных версиях не рекомендуется.

Серверы HTTPS на основе имени

Распространенная проблема возникает при настройке двух и более серверов HTTPS.
прослушивание одного IP-адреса:

server {
    слушайте 443 ssl;
    имя_сервера www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    слушайте 443 ssl;
    имя_сервера www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

В этой конфигурации браузер получает сертификат сервера по умолчанию,
т.е. www.example.com независимо от запрошенного имени сервера.
Это вызвано поведением протокола SSL.
SSL-соединение устанавливается до того, как браузер отправит HTTP-запрос.
и nginx не знает имя запрошенного сервера.Следовательно, он может предлагать только сертификат сервера по умолчанию.

Самый старый и надежный метод решения проблемы
— назначить отдельный IP-адрес для каждого HTTPS-сервера:

server {
    слушайте 192.168.1.1:443 ssl;
    имя_сервера www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    слушайте 192.168.1.2:443 ssl;
    имя_сервера www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}
SSL-сертификат с несколькими именами

Есть и другие способы, позволяющие использовать один IP-адрес.
между несколькими серверами HTTPS.Однако у всех есть свои недостатки.
Один из способов — использовать сертификат с несколькими именами в
поле сертификата SubjectAltName, например,
www.example.com и www.example.org .
Однако длина поля SubjectAltName ограничена.

Другой способ — использовать сертификат с подстановочным именем, например,
* .example.org .
Подстановочный сертификат защищает все поддомены указанного домена,
но только на одном уровне.
Этот сертификат соответствует www.example.org , но не соответствует
example.org и www.sub.example.org .
Эти два метода также можно комбинировать.
Сертификат может содержать точные имена и имена с подстановочными знаками в
Поле SubjectAltName, например,
example.org и * .example.org .

Лучше разместить файл сертификата с несколькими именами и
его файл закрытого ключа на уровне конфигурации http
чтобы унаследовать их единственную копию памяти на всех серверах:

ssl_certificate общий.crt;
ssl_certificate_key common.key;

server {
    слушайте 443 ssl;
    имя_сервера www.example.com;
    ...
}

server {
    слушайте 443 ssl;
    имя_сервера www.example.org;
    ...
}
Указание имени сервера

Более универсальное решение для запуска нескольких серверов HTTPS на одном
IP-адрес
TLS
Расширение индикации имени сервера (SNI, RFC 6066),
который позволяет браузеру передавать запрошенное имя сервера во время подтверждения SSL
и, следовательно, сервер будет знать, какой сертификат он должен использовать
для связи.SNI в настоящее время
поддержанный
большинством современных браузеров, хотя может не использоваться некоторыми старыми или специальными клиентами.

В SNI можно передавать только доменные имена,
однако некоторые браузеры могут ошибочно передавать IP-адрес сервера
в качестве имени, если запрос включает буквальный IP-адрес.
На это не стоит полагаться.

Чтобы использовать SNI в nginx, он должен поддерживаться как в
Библиотека OpenSSL, с помощью которой был собран двоичный файл nginx, а также
библиотека, с которой он динамически подключается во время выполнения.OpenSSL поддерживает SNI с версии 0.9.8f, если он был построен с опцией конфигурации
«—Enable-tlsext».
Начиная с OpenSSL 0.9.8j, эта опция включена по умолчанию.
Если nginx был собран с поддержкой SNI, то nginx покажет это
при запуске с переключателем «-V»:

$ nginx -V
...
Поддержка TLS SNI включена
...

Однако, если nginx с поддержкой SNI динамически связан с
библиотека OpenSSL без поддержки SNI, nginx отображает предупреждение:

nginx был построен с поддержкой SNI, однако теперь он связан
динамически в библиотеку OpenSSL, которая не поддерживает tlsext,
поэтому SNI недоступен
Совместимость
  • Статус поддержки SNI отображается переключателем «-V».
    с 0.8.21 и 0.7.62.
  • Параметр ssl
    Слушать
    директива поддерживается с 0.7.14.
    До 0.8.21 его можно было указать только вместе с
    по умолчанию параметр.
  • SNI поддерживается с 0.5.23.
  • Общий кеш сеанса SSL поддерживается с версии 0.5.6.
  • Версия 1.9.1 и новее: протоколы SSL по умолчанию — TLSv1,
    TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
  • Версия 0.7.65, 0.8.19 и новее: протоколы SSL по умолчанию — SSLv3, TLSv1,
    TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
  • Версия 0.7.64, 0.8.18 и более ранние: протоколы SSL по умолчанию — SSLv2,
    SSLv3 и TLSv1.
  • Версия 1.0.5 и новее: шифры SSL по умолчанию
    « HIGH:! ANULL:! MD5 ».
  • Версия 0.7.65, 0.8.20 и новее: шифры SSL по умолчанию
    « ВЫСОКИЙ:! ADH:! MD5 ».
  • Версия 0.8.19: шифры SSL по умолчанию:
    « ALL:! ADH: RC4 + RSA: + HIGH: + MEDIUM ».
  • Версия 0.7.64, 0.8.18 и более ранние: шифры SSL по умолчанию:
    « ALL:! ADH: RC4 + RSA: + HIGH: + MEDIUM: + LOW: + SSLv2: + EXP ».
написано Игорем Сысоевым
отредактировано Брайаном Мерсером

Майор Хайден 🤠 — Мудрые слова от социального ботаника

Один из самых удобных инструментов в наборе инструментов OpenSSL — s_client . Вы можете быстро просмотреть подробную информацию о сертификатах SSL, установленных на конкретном сервере, и диагностировать проблемы.Например, используйте эту команду для просмотра сертификатов SSL Google:

  openssl s_client -connect encrypted.google.com:443

Вы увидите цепочку сертификатов, возвращающуюся к исходному центру сертификации, где Google купил его сертификат, вверху, копию их сертификата SSL в виде обычного текста посередине и кучу информации, связанной с сеансом, внизу. .

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

Если вы попытаетесь подключиться к rackerhacker.com с помощью s_client , вы обнаружите, что получаете сертификат SSL по умолчанию, установленный на моем сервере, а не тот, который используется для этого сайта:

  $ openssl s_client -connect rackerhacker.com: 443
Цепочка сертификатов
 0 с: / C = США / ST = Техас / L = Сан-Антонио / O = MHTX Enterprises / CN = *. Mhtx.net
   i: / C = US / O = SecureTrust Corporation / CN = SecureTrust CA
 1 с: / C = US / O = SecureTrust Corporation / CN = SecureTrust CA
   я: /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. по исх. (ограничивает ответственность) / OU = (c) 1999 Entrust.net Limited / CN = Entrust.net Secure Server Certification Authority

Добавьте аргумент -servername , и s_client выполнит за вас дополнительный шаг согласования SNI:

  $ openssl s_client -connect rackerhacker.com: 443 -servername rackerhacker.com
Цепочка сертификатов
 0 с: / OU = Контроль домена подтвержден / OU = PositiveSSL / CN = rackerhacker.com
   i: / C = GB / ST = Большой Манчестер / L = Salford / O = Comodo CA Limited / CN = PositiveSSL CA
 1 с: / C = GB / ST = Большой Манчестер / L = Salford / O = Comodo CA Limited / CN = PositiveSSL CA
   i: / C = US / ST = UT / L = Солт-Лейк-Сити / O = Сеть USERTRUST / OU = http: //www.usertrust.com/CN=UTN-USERFirst-Hardware
 2 с: / C = US / ST = UT / L = Солт-Лейк-Сити / O = Сеть USERTRUST / OU = http: //www.usertrust.com/CN=UTN-USERFirst-Hardware
   i: / C = SE / O = AddTrust AB / OU = AddTrust External TTP Network / CN = AddTrust External CA Root
 3 с: / C = SE / O = AddTrust AB / OU = AddTrust External TTP Network / CN = AddTrust External CA Root
   i: / C = SE / O = AddTrust AB / OU = AddTrust External TTP Network / CN = AddTrust External CA Root

Вы можете задать себе этот вопрос:

Почему веб-сервер просто не использует заголовок Host: , который мой браузер уже отправляет, чтобы определить, какой сертификат SSL использовать?

Имейте в виду, что согласование SSL должно происходить за до , чтобы отправить HTTP-запрос на удаленный сервер.Это означает, что браузер и сервер должны произвести обмен сертификатами на более раннем этапе процесса, и у браузера не будет возможности указать, на какой сайт он пытается попасть. SNI исправляет это, разрешая тип обмена заголовком Host: во время процесса согласования SSL.

Использование нескольких сертификатов сервера SSL в Web Dispatcher — Инфраструктура сервера приложений

Назначение

Покажите примеры того, как настроить несколько сертификатов сервера SSL в Web Dispatcher.

Обзор

Web Dispatcher и ICM могут работать с несколькими сертификатами сервера SSL.

Это полезно, когда конечные пользователи могут подключиться к системе через разные имена хостов.

Этот сценарий более распространен для Web Dispatcher, поэтому мы сосредоточены на нем (см. Настройка Web Dispatcher для нескольких систем — пояснения и примеры).

Однако те же настройки и параметры будут работать с ICM.

Параметр icm / ssl_config_

Параметр icm / ssl_config_ можно использовать для настройки нескольких сертификатов SSL.

Позже это можно использовать с аргументом SSLCONFIG параметра icm / server_port_ , который затем определит сертификат сервера SSL, который будет использоваться для обработки запросов, которые достигли Web Dispatcher через этот порт HTTPS.

Предварительные условия и возможные сценарии

СЦЕНАРИЙ 1:

Каждый порт HTTPS может быть связан с одним сертификатом сервера SSL.

Следовательно, если необходимо использовать несколько сертификатов сервера SSL, необходимо открыть несколько портов HTTPS в веб-диспетчере.

Для этого есть два варианта:

  1. Вы хотите / должны использовать номер порта HTTPS по умолчанию (порт TCP 443) при всех доступах HTTPS.
    В этом случае сервер, на котором работает Web Dispatcher, должен иметь один IP-адрес на каждый сертификат сервера SSL;
  2. Номер порта не важен.
    В этом случае сервер Web Dispatcher может иметь один IP-адрес и использовать разные номера портов (например, 443 и 444).

СЦЕНАРИЙ 2:

Используйте SNI (указание имени сервера), чтобы назначить несколько сертификатов SSL одному порту HTTPS.

Требуется версия Web Dispatcher 7.45 (или выше).

Сценарий 1: Пример с двумя именами хостов — двумя IP-адресами и портом 443

На сервере Web Dispatcher настроено два IP-адреса.

Каждый IP-адрес связан с другим именем хоста.

Например:

portal.example.com — IP-адрес: 10.10.10.10
ecc.example.com — IP-адрес: 10.10.10.20

Сертификат сервера SSL для «portal.example.com» хранился в «портал.pse «и сертификат для» ecc.example.com «в файле» ecc.pse «.

Это параметры, которые необходимо установить:

# Это также может быть» portal.pse «, это не имеет значения
ssl / server_pse = ecc.pse

# Сертификат для portal.example.com
icm / ssl_config_0 = CRED = portal.pse
# Сертификат для ecc.example.com
icm / ssl_config_1 = CRED = ecc.pse

# Открытие порта для ECC
icm / server_port_0 = PROT = HTTPS, PORT = 443, HOST = 10.10.10.20, SSLCONFIG = ssl_config_1
# Открытие порта для портала
icm / server_port_1 = PROT = HTTPS, PORT = 443, HOST = 10.10.10.10, SSLCONFIG = ssl_config_0

Как видно из приведенных выше параметров, число, используемое в «icm / ssl_config_ X » не обязательно должен соответствовать номеру определения порта (icm / server_port_ X ).

Порт 443 можно использовать дважды, поскольку аргумент «HOST» в определениях портов ограничивает открытие порта определенным IP-адресом.

Сценарий 1: Пример с двумя именами хостов — один IP-адрес и разные порты

На сервере Web Dispatcher настроен только один IP-адрес.

Два имени хоста указывают на сервер Web Dispatcher с использованием псевдонимов DNS.

Рассмотрим те же имена хостов, которые использовались в предыдущем разделе.

Это параметры, которые необходимо установить:

# Это также может быть «portal.pse», не имеет значения
ssl / server_pse = ecc.pse

# Сертификат для портала.example.com
icm / ssl_config_0 = CRED = portal.pse
# Сертификат для ecc.example.com
icm / ssl_config_1 = CRED = ecc.pse

# Открытие порта для ECC
icm / server_port_0 = PROT = HTTPS, PORT = 444, SSLCONFIG = ssl_config_1
# Открытие порта для портала
icm / server_port_1 = PROT = HTTPS, PORT = 443, SSLCONFIG = ssl_config_0

Сценарий 2: Пример с двумя именами хостов, одним IP-адресом, одним портом SNI

На сервере Web Dispatcher настроен только один IP-адрес.

Два имени хоста указывают на сервер Web Dispatcher с использованием псевдонимов DNS.

Рассмотрим те же имена хостов, которые использовались в предыдущих разделах.

Это параметры, которые необходимо установить:

# Сертификаты для portal.example.com и ecc.example.com — с использованием SNI
icm / ssl_config_0 = CRED = SAPSSLS.pse, SNI_CREDS = ecc.pse; portal .pse

# Открытие порта для обоих имен хостов / сертификатов SSL — с использованием SNI
icm / server_port_0 = PROT = HTTPS, PORT = 443, SSLCONFIG = ssl_config_0

Подстановочные сертификаты не могут использоваться для SNI.

Для использования сертификата с подстановочными знаками его можно было установить только с помощью опции «CRED» в «icm / ssl_config_ », установив остальные используемые сертификаты (без подстановочных знаков) вместо опции «SNI_CREDS» того же параметра.

Параметр icm / ssl_config_

Параметр icm / server_port_

Настройка веб-диспетчера для нескольких систем — пояснения и примеры

Настройка SAP Web Dispatcher для поддержки SSL

SAP-примечание 2203500: ICM / Web Dispatcher : Индикация имени сервера расширения TLS (SNI) в качестве сервера

SAP-нота 908097: SAP Web Dispatcher: выпуск, установка, исправления, документация

SAP-нота 2009483: Управление PSE в интерфейсе веб-администрирования SAP Web Dispatcher

SAP KBA 2160678: Система единого входа перестает работать при настройке параметра icm / HTTPS / trust_client_with *.

SAP KBA 2502649: создание сертификатов с альтернативным именем субъекта (SAN) через страницу веб-администратора

SAP KBA 2527968: сертификаты SSL WildCard для SNI

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *