Настройка SSL#
Чтобы настроить HTTPS-сервер, необходимо включить параметр ssl на слушающих сокетах в блоке server, а также указать местоположение файлов с сертификатом сервера и секретным ключом:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
#...
}
Сертификат сервера является публичным. Он посылается каждому клиенту, соединяющемуся с сервером. Секретный ключ следует хранить в файле с ограниченным доступом (права доступа должны позволять главному процессу Angie читать этот файл). Секретный ключ можно также хранить в одном файле с сертификатом.
ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
При этом права доступа к файлу следует также ограничить. Несмотря на то, что и сертификат, и ключ хранятся в одном файле, клиенту посылается только сертификат.
С помощью директив ssl_protocols и ssl_ciphers можно ограничить соединения использованием только "сильных" версий и шифров SSL/TLS. По умолчанию Angie использует:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
Поэтому их явная настройка в общем случае не требуется. SSL-операции потребляют дополнительные ресурсы процессора. На мультипроцессорных
системах следует запускать несколько рабочих процессов, не меньше числа доступных процессорных ядер. Наиболее
ресурсоемкой для процессора является операция SSL-рукопожатия, в рамках которого
формируются криптографические параметры сессии. Существует два способа
уменьшения числа этих операций, производимых для каждого клиента: использование
постоянных (keepalive) соединений, позволяющих в
рамках одного соединения обрабатывать сразу несколько запросов, и повторное
использование параметров SSL-сессии для предотвращения необходимости выполнения
SSL-рукопожатия для параллельных и последующих соединений. Сессии хранятся в
кэше SSL-сессий, разделяемом между рабочими процессами и настраиваемом
директивой ssl_session_cache. В 1 мегабайт кэша помещается около 4000
сессий. Таймаут кэша по умолчанию равен 5 минутам. Он может быть увеличен с
помощью директивы ssl_session_timeout. Вот пример конфигурации,
оптимизированной под многоядерную систему с 10-мегабайтным разделяемым кэшем
сессий: Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном
общеизвестным центром сертификации, в то время как другие браузеры без проблем
принимают этот же сертификат. Так происходит потому, что центр, выдавший
сертификат, подписал его промежуточным сертификатом, которого нет в базе данных
сертификатов общеизвестных доверенных центров сертификации, распространяемой
вместе с браузером. В подобном случае центр сертификации предоставляет "связку"
сертификатов, которую следует присоединить к сертификату сервера. Сертификат
сервера следует разместить перед связкой сертификатов в скомбинированном файле: Полученный файл следует указать в директиве ssl_certificate: Если сертификат сервера и связка сертификатов были соединены в неправильном
порядке, Angie не запустится и выдаст сообщение об ошибке, например такое
(текст после Это происходит потому, что Angie пытается использовать секретный ключ с первым
сертификатом из связки вместо сертификата сервера. Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные
доверенными центрами сертификации, поэтому активно используемые браузеры уже
могут иметь требуемые промежуточные сертификаты и не выдать предупреждение о
сертификате, присланном без связанной с ним цепочки сертификатов. Убедиться в
том, что сервер присылает полную цепочку сертификатов, можно при помощи утилиты
командной строки openssl, например: Совет В этом примере субъект ("s") сертификата №0 сервера www.GoDaddy.com подписан
издателем ("i"), который в свою очередь является субъектом сертификата №1,
подписанного издателем, который в свою очередь является субъектом сертификата
№2, подписанного общеизвестным издателем ValiCert, Inc., чей сертификат хранится
во встроенной в браузеры базе данных сертификатов. Если связку сертификатов не добавили, будет показан только сертификат сервера
под номером 0. Можно настроить единый сервер, который обслуживает как HTTP-, так и
HTTPS-запросы: Типичная проблема возникает при настройке двух и более HTTPS-серверов, слушающих
на одном и том же IP-адресе: В такой конфигурации браузер получит сертификат сервера по умолчанию, т. е.
Наиболее старым и надежным способом решения этой проблемы является назначение
каждому HTTPS-серверу своего IP-адреса: Существуют и другие способы, позволяющие использовать один и тот же IP-адрес
сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки.
Одним из таких способов является использование сертификата с несколькими именами
в поле Другим способом является использование wildcard-сертификата, например
Лучше всего разместить файл сертификата с несколькими именами и его секретный
ключ на уровне конфигурации http, чтобы все серверы унаследовали их
единственную копию в памяти. Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе —
расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет
браузеру передать запрашиваемое имя сервера во время SSL-рукопожатия, а значит,
сервер будет знать, какой сертификат ему следует использовать для соединения.
Сейчас SNI поддерживается большинством современных браузеров, однако может не
использоваться некоторыми старыми или специализированными клиентами. Совет В SNI можно передавать только доменные имена, однако некоторые браузеры могут
ошибочно передавать IP-адрес сервера в качестве его имени, если в запросе
указан IP-адрес. На это не следует полагаться. Если Angie был собран с поддержкой SNI, то при запуске Angie с ключом
Однако если Angie, собранный с поддержкой SNI, в процессе работы подгружает
библиотеку OpenSSL, в которой нет поддержки SNI, Angie выдает
предупреждение:Оптимизация HTTPS-сервера#
worker_processes auto;
http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
server {
listen 443 ssl;
server_name www.example.com;
keepalive_timeout 70;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
#...
Цепочки SSL-сертификатов#
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
#...
}
SSL: формирует OpenSSL, и его формулировка зависит от
версии OpenSSL):SSL_CTX_use_PrivateKey("/etc/angie/www.example.com.key") failed (SSL: error:05800074:x509 certificate routines::key values mismatch)
$ 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
openssl s_client передает в SNI имя хоста из
-connect; чтобы проверить другое имя, укажите его ключом
-servername, а чтобы увидеть, что получит клиент без SNI,
добавьте ключ -noservername.Единый HTTP/HTTPS сервер#
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
#...
}
Выбор HTTPS-сервера по имени#
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
#...
}
server {
listen 443 ssl;
server_name www.example.org;
ssl_certificate www.example.org.crt;
#...
}
www.example.com, независимо от запрашиваемого имени сервера. Это связано с
поведением протокола SSL. SSL-соединение устанавливается до того, как браузер
посылает HTTP-запрос, и Angie не знает имени запрашиваемого сервера.
Следовательно, он лишь может предложить сертификат сервера по умолчанию.server {
listen 192.168.1.1:443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
#...
}
server {
listen 192.168.1.2:443 ssl;
server_name www.example.org;
ssl_certificate www.example.org.crt;
#...
}
SSL-сертификат с несколькими именами#
SubjectAltName сертификата, например www.example.com и
www.example.org. Однако длина поля SubjectAltName ограничена.*.example.org. Такой сертификат защищает все поддомены указанного домена, но
только на заданном уровне. Под такой сертификат подходит www.example.org, но
не подходят example.org и www.sub.example.org. Эти два метода также могут
быть объединены. Сертификат может содержать как точные, так и wildcard-имена в
поле SubjectAltName, например example.org и *.example.org.ssl_certificate common.crt;
ssl_certificate_key common.key;
server {
listen 443 ssl;
server_name www.example.com;
#...
}
server {
listen 443 ssl;
server_name www.example.org;
#...
}
Указание имени сервера#
-V об этом сообщается:$ sudo angie -V
...
TLS SNI support enabled
...
Angie 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
Содержание