+ +

+ + +Чтобы настроить HTTPS-сервер, необходимо включить протокол SSL +в блоке server, а также указать местоположение файлов с +сертификатом сервера и секретным ключом: + + +server { + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ssl_protocols SSLv3 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/TLS. +Начиная с версии 1.0.5 nginx по умолчанию использует +“ssl_protocols SSLv3 TLSv1” и +“ssl_ciphers HIGH:!aNULL:!MD5”, +поэтому явная их настройка имеет смысл только для более ранних версий nginx. +Начиная с версий 1.1.13 и 1.0.12 nginx по умолчанию использует +“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”. + + + +Известно, что шифры с CBC-режимом уязвимы к ряду атак, в частности +к BEAST-атаке (см. +CVE-2011-3389). +Настройка шифров может быть изменена так, чтобы предпочитался RC4-SHA: + + + ssl_ciphers RC4:HIGH:!aNULL:!MD5; + ssl_prefer_server_ciphers on; + + + +

+ + +

+ + +SSL-операции потребляют дополнительные ресурсы процессора. +На мультипроцессорных системах следует запускать несколько рабочих процессов, +не меньше числа доступных процессорных ядер. +Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках +которой формируются криптографические параметры сессии. +Существует два способа уменьшения числа этих операций, производимых для каждого +клиента: включение постоянных (keepalive) соединений, позволяющих в рамках +одного соединения обрабатывать сразу несколько запросов, и повторное +использование параметров SSL-сессии для предотвращения необходимости выполнения +SSL handshake для параллельных и последующих соединений. +Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и +настраиваемом директивой +. +В 1 мегабайт кэша помещается около 4000 сессий. +Таймаут кэша по умолчанию равен 5 минутам. +Он может быть увеличен с помощью директивы +. +Вот пример конфигурации, оптимизированной под 4-ядерную систему +с 10M разделяемого кэша сессий: + + +worker_processes 4; + +http { + ssl_session_cache shared:SSL:10m; + ssl_session_timeout 10m; + + server { + listen 443; + server_name www.example.com; + keepalive_timeout 70; + + ssl on; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; + ssl_ciphers HIGH:!aNULL:!MD5; + ... + + + +

+ + +

+ + +Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном +общеизвестным центром сертификации, в то время как другие браузеры без +проблем принимают этот же сертификат. +Так происходит потому, что центр, выдавший сертификат, подписал его +промежуточным сертификатом, которого нет в базе данных сертификатов +общеизвестных доверенных центров сертификации, распространяемой +вместе с браузером. +В подобном случае центр сертификации предоставляет “связку” сертификатов, +которую следует присоединить к сертификату сервера. +Сертификат сервера следует разместить перед связкой сертификатов +в скомбинированном файле: + + +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt + + +Полученный файл следует указать в директиве +: + + +server { + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; + ... +} + + +Если сертификат сервера и связка сертификатов были соединены в неправильном +порядке, nginx откажется запускаться и выдаст сообщение об ошибке: + + +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed + (SSL: error:0B080074:x509 certificate routines: + X509_check_private_key:key values mismatch) + + +поскольку nginx попытается использовать секретный ключ с первым +сертификатом из связки вместо сертификата сервера. + + + +Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные +доверенными центрами сертификации, поэтому активно используемые браузеры +уже могут иметь требуемые промежуточные сертификаты и не выдать предупреждение +о сертификате, присланном без связанной с ним цепочки сертификатов. +Убедиться в том, что сервер присылает полную цепочку сертификатов, +можно при помощи утилиты командной строки openssl, например: + + +$ openssl s_client -connect www.godaddy.com:443 +... +Certificate chain + 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US + /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, Clause 5.(b) + i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. + /OU=http://certificates.godaddy.com/repository + /CN=Go Daddy Secure Certification Authority + /serialNumber=07969287 + 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. + /OU=http://certificates.godaddy.com/repository + /CN=Go Daddy Secure Certification Authority + /serialNumber=07969287 + i:/C=US/O=The Go Daddy Group, Inc. + /OU=Go Daddy Class 2 Certification Authority + 2 s:/C=US/O=The Go Daddy Group, Inc. + /OU=Go Daddy Class 2 Certification Authority + i:/L=ValiCert Validation Network/O=ValiCert, Inc. + /OU=ValiCert Class 2 Policy Validation Authority + /CN=http://www.valicert.com//emailAddress=info@valicert.com +... + + +В этом примере субъект (“s”) сертификата №0 сервера +www.GoDaddy.com подписан издателем (“i”), +который в свою очередь является субъектом сертификата №1, подписанного +издателем, который в свою очередь является субъектом сертификата №2, +подписанного общеизвестным издателем ValiCert, Inc., +чей сертификат хранится во встроенной в браузеры базе данных +сертификатов (которая в тёмном чулане хранится в доме, который построил Джек). + + + +Если связку сертификатов не добавили, будет показан только сертификат +сервера №0. + + +

+ + +

+ + +На практике рекомендуется с самого начала настраивать отдельные серверы +для протоколов HTTP и HTTPS. +И хотя сегодня их функциональность может казаться идентичной, в будущем +это может измениться и использование консолидированного сервера может +стать проблематичным. +Однако, если серверы HTTP и HTTPS идентичны, и думать о будущем не +хочется, можно настроить единый сервер, который обслуживает +как HTTP-, так и HTTPS-запросы. +Для этого следует исключить директиву “ssl on” +и добавить параметр ssl к порту *:443: + + +server { + listen 80; + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ... +} + + + +До версии 0.8.21 nginx допускал указание параметра ssl +на слушающем сокете только совместно с параметром default: + +listen 443 default ssl; + + + + +

+ + +

+ + +Типичная проблема возникает при настройке двух и более серверов HTTPS, +слушающих на одном и том же IP-адресе: + + +server { + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.crt; + ... +} + +server { + listen 443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; + ... +} + + +В такой конфигурации браузер получит сертификат первого сервера, т.е. +www.example.com, независимо от запрашиваемого имени сервера. +Это связано с поведением протокола SSL. +SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, +и nginx не знает имени запрашиваемого сервера. +Следовательно, он лишь может предложить сертификат сервера по умолчанию. + + + +Наиболее старым и надёжным способом решения этой проблемы +является назначение каждому HTTPS-серверу своего IP-адреса: + + +server { + listen 192.168.1.1:443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.crt; + ... +} + +server { + listen 192.168.1.2:443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; + ... +} + + + +

+ + +

+ + +Существуют и другие способы, которые позволяют использовать один и тот же +IP-адрес сразу для нескольких HTTPS-серверов. +Все они, однако, имеют свои недостатки. +Одним из таких способов является использование сертификата с несколькими +именами в поле SubjectAltName сертификата, например www.example.com +и www.example.org. +Однако, длина поля SubjectAltName ограничена. + + + +Другим способом является использование wildcard-сертификата, например +*.example.org. +Такой сертификат защищает все поддомены указанного домена, но только +на заданном уровне. +Под такой сертификат подходит www.example.org, но не подходят +example.org и www.sub.example.org. +Два вышеуказанных способа можно комбинировать. +Сертификат может одновременно содержать и точное, и wildcard имена в поле +SubjectAltName, например example.org и *.example.org. + + + +Лучше поместить сведения о файле сертификата с несколькими именами и +файле с его секретным ключом на уровне конфигурации http, чтобы +все серверы унаследовали их единственную копию в памяти: + + +ssl_certificate common.crt; +ssl_certificate_key common.key; + +server { + listen 443; + server_name www.example.com; + ssl on; + ... +} + +server { + listen 443; + server_name www.example.org; + ssl on; + ... +} + + + +

+ + +

+ + +Более общее решение для работы нескольких HTTPS-серверов на одном +IP-адресе — +расширение +TLSv1.1 Server Name Indication (SNI, RFC3546), +которое позволяет браузеру передать запрашиваемое имя сервера во время +SSL handshake, а значит сервер будет знать, какой сертификат ему +следует использовать для соединения. +Однако, поддержка SNI браузерами ограничена. +Сейчас это поддерживается браузерами начиная со следующих версий: + + + + + +Opera 8.0; + + + +MSIE 7.0 (но только на Windows Vista и выше); + + + +Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1; + + + +Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше); + + + +и Chrome (Windows-версия также поддерживает SNI только на Vista и выше). + + + + + +Чтобы использовать SNI в nginx, соответствующая поддержка должна +присутствовать как в библиотеке OpenSSL, использованной при сборке +бинарного файла nginx, так и в библиотеке, подгружаемой в момент +работы. +OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была +собрана с опцией конфигурации “--enable-tlsext”. +Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. +Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом +“-V” об этом сообщается: + + +$ nginx -V +... +TLS SNI support enabled +... + + +Однако, если nginx, собранный с поддержкой SNI, в процессе работы подгружает +библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение: + + +nginx was built with SNI support, however, now it is linked +dynamically to an OpenSSL library which has no tlsext support, +therefore SNI is not available + + + +

+ + +

+ + + + + +Статус поддержки SNI отображается по ключу “-V” +начиная с версий 0.8.21 и 0.7.62. + + + +Параметр ssl директивы + +поддерживается начиная с версии 0.7.14. + + + +SNI поддерживается начиная с версии 0.5.32. + + + +Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6. + + + + + + + + + +Версия 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 по умолчанию являются +“HIGH:!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”. + + + + + + +

+ + +