Apache Module mod_ssl

Директива SSLCACertificateFile

SSLCACertificateFile file-path

Данная директива устанавливает единый файл, где вы можете собрать сертификаты Удостоверяющих центров (УЦ), клиентов которых вы используете. Они используются для проверки клиентов. Такой файл представляет собой просто конкатенацию различных файлов сертификатов в формате PEM в порядке приоритета. Его можно использовать как альтернативу и/или дополнительно к SSLCACertificatePath.

SSLCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt"

Директива SSLCACertificatePath

SSLCACertificatePath directory-path

Данная директива устанавливает директорию, в которой хранятся сертификаты Удостоверяющих центров (УЦ), клиентов которых вы используете. Они используются для проверки сертификата клиента при аутентификации клиента.

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

SSLCACertificatePath "/usr/local/apache2/conf/ssl.crt/"

Директива SSLCADNRequestFile

SSLCADNRequestFile file-path

При запросе сертификата клиента mod_ssl клиенту отправляется список допустимых имен Удостоверяющих центров. Эти имена CA могут использоваться клиентом для выбора соответствующего сертификата клиента из имеющихся у него.

Если ни одна из директив SSLCADNRequestPath или SSLCADNRequestFile не указана, тогда множество допустимых имен CA, отправляемых клиенту, состоит из имен всех сертификатов CA, заданных директивами SSLCACertificateFile и SSLCACertificatePath; другими словами, имен УЦ, которые будут фактически использоваться для проверки сертификата клиента.

В некоторых ситуациях полезно иметь возможность отправлять набор допустимых имен CA, который отличается от фактических CA, используемых для проверки сертификата клиента — например, если сертификаты клиента подписаны промежуточными УЦ. В таких случаях можно использовать SSLCADNRequestPath и/или SSLCADNRequestFile; допустимые имена CA затем берутся из полного набора сертификатов в указанной папке и/или файле этой парой директив.

SSLCADNRequestFile должен указывать единый файл, содержащий конкатенацию сертификатов CA в формате PEM.

SSLCADNRequestFile "/usr/local/apache2/conf/ca-names.crt"

Директива SSLCADNRequestPath

SSLCADNRequestPath directory-path

Эта необязательная директива может использоваться для указания набора допустимых имен CA, которые будут отправлены клиенту при запросе сертификата клиента. Смотрите директиву SSLCADNRequestFile для получения дополнительной информации.

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

SSLCADNRequestPath "/usr/local/apache2/conf/ca-names.crt/"

Директива SSLCARevocationCheck

SSLCARevocationCheck chain|leaf|none [flags ...]

SSLCARevocationCheck none

Включает проверку отзыва сертификатов на основе списка отозванных сертификатов (CRL). По крайней мере, один из SSLCARevocationFile или SSLCARevocationPath должен быть настроен. При установке на chain (рекомендуемое значение), проверки CRL применяются ко всем сертификатам в цепочке, в то время как установка на leaf ограничивает проверки сертификатом конечного пользователя.

Доступные флаги:

• no_crl_for_cert_ok

  До версии 2.3.15, проверка CRL в mod_ssl также выполнялась успешно, когда ни один CRL для проверяемого сертификата не был найден ни в одном из мест, настроенных с помощью SSLCARevocationFile или SSLCARevocationPath.

  С введением SSLCARevocationFile, поведение было изменено: по умолчанию с chain или leaf, CRL должны присутствовать для успешной валидации — в противном случае она завершится ошибкой "unable to get certificate CRL".

  Флаг no_crl_for_cert_ok позволяет восстановить предыдущее поведение.

SSLCARevocationCheck chain

SSLCARevocationCheck chain no_crl_for_cert_ok

Директива SSLCARevocationFile

SSLCARevocationFile file-path

Данная директива устанавливает единый файл, где вы можете собрать списки отозванных сертификатов (CRL) Удостоверяющих центров (УЦ), клиентов которых вы используете. Они используются для проверки клиентов. Такой файл представляет собой просто конкатенацию различных файлов CRL в формате PEM в порядке приоритета. Его можно использовать как альтернативу и/или дополнительно к SSLCARevocationPath.

SSLCARevocationFile "/usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl"

Директива SSLCARevocationPath

SSLCARevocationPath directory-path

Данная директива устанавливает директорию, в которой хранятся списки отозванных сертификатов (CRL) Удостоверяющих центров (УЦ), клиентов которых вы используете. Они используются для отзыва сертификата клиента при аутентификации клиента.

Файлы в этой директории должны быть в формате PEM и доступны через имена файлов с хешем. Поэтому обычно вы не можете просто поместить файлы CRL туда: вам также необходимо создать символические ссылки с именами значение-хеша.rN. И вы всегда должны убедиться, что эта директория содержит соответствующие символические ссылки.

SSLCARevocationPath "/usr/local/apache2/conf/ssl.crl/"

Директива SSLCertificateChainFile

SSLCertificateChainFile file-path

Эта директива устанавливает необязательный файл, в котором можно собрать сертификаты центров сертификации (CA), образующие цепочку сертификатов сервера. Она начинается с сертификата выпустившего CA серверного сертификата и может доходить до корневого сертификата CA. Такой файл представляет собой просто конкатенацию различных файлов сертификатов CA в PEM-кодировании, обычно в порядке цепочки сертификатов.

Это следует использовать как альтернативу и/или дополнение к SSLCACertificatePath для явного построения цепочки сертификатов сервера, которая отправляется браузеру в дополнение к сертификату сервера. Она особенно полезна для предотвращения конфликтов с сертификатами CA при использовании аутентификации клиента. Потому что, хотя размещение сертификата CA цепочки серверного сертификата в SSLCACertificatePath имеет тот же эффект для построения цепочки сертификатов, оно имеет побочный эффект, что сертификаты клиентов, выпущенные этим же сертификатом CA, также принимаются при аутентификации клиента.

Но будьте осторожны: Предоставление цепочки сертификатов работает только если вы используете один сертификат сервера на основе RSA или DSA. Если вы используете пару сертификатов RSA+DSA, это сработает только если оба сертификата используют одну и ту же цепочку сертификатов. В противном случае браузеры будут введены в заблуждение в этой ситуации.

SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/ca.crt"

Директива SSLCertificateFile

SSLCertificateFile file-path|certid

Эта директива указывает на файл с данными сертификата в формате PEM или идентификатор сертификата через настроенный криптографический токен. Если используется файл PEM, то по крайней мере, файл должен содержать сертификат конечного узла (листовой сертификат). Директива может использоваться несколько раз (ссылаясь на разные имена файлов) для поддержки нескольких алгоритмов проверки подлинности сервера — обычно RSA, DSA и ECC. Количество поддерживаемых алгоритмов зависит от используемой версии OpenSSL для mod_ssl: с версией 1.0.0 или более поздней, openssl list-public-key-algorithms выведет список поддерживаемых алгоритмов, см. также примечание ниже о ограничениях версий OpenSSL, предшествующих 1.0.2, и способах их обхода.

Файлы также могут содержать промежуточные сертификаты CA, от листового к корневому. Это поддерживается с версии 2.4.8 и более поздними версиями и делает SSLCertificateChainFile устаревшим. При работе с OpenSSL 1.0.2 или более поздними версиями это позволяет настроить цепочку промежуточных CA для каждого сертификата.

Также могут быть добавлены пользовательские параметры DH и имя кривой EC для эфемерных ключей в конце первого файла, настроенного с помощью SSLCertificateFile. Это поддерживается в версии 2.4.7 или более поздних. Такие параметры можно сгенерировать с помощью команд openssl dhparam и openssl ecparam. Параметры могут быть добавлены как есть в конец первого файла сертификата. Только первый файл может быть использован для пользовательских параметров, так как они применяются независимо от типа алгоритма аутентификации.

Наконец, закрытый ключ конечного сертификата также может быть добавлен в файл сертификата вместо использования отдельной директивы SSLCertificateKeyFile. Эта практика крайне не рекомендуется. Если она используется, файлы сертификатов, использующие такой встроенный ключ, должны быть настроены после сертификатов, использующих отдельный файл ключа. Если закрытый ключ зашифрован, диалог с запросом пароля будет вынужденно появляться при запуске.

В качестве альтернативы хранению сертификатов и закрытых ключей в файлах, может быть использован идентификатор сертификата для идентификации сертификата, хранящегося в токене. В настоящее время только PKCS#11 URI распознаются как идентификаторы сертификатов и могут быть использованы в сочетании с OpenSSL pkcs11 модулем. Если SSLCertificateKeyFile опущен, сертификат и закрытый ключ могут быть загружены через единственный идентификатор, указанный с помощью SSLCertificateFile.

# Example using a PEM-encoded file.
SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"
# Example use of a certificate and private key from a PKCS#11 token:
SSLCertificateFile "pkcs11:token=My%20Token%20Name;id=45"

Директива SSLCertificateKeyFile

SSLCertificateKeyFile file-path|keyid

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

Директива может использоваться несколько раз (ссылаясь на разные имена файлов) для поддержки нескольких алгоритмов проверки подлинности сервера. Для каждой директивы SSLCertificateKeyFile, должна быть соответствующая директива SSLCertificateFile.

Закрытый ключ также может быть объединён с сертификатом в файле, заданном директивой SSLCertificateFile, но эта практика крайне не рекомендуется. Если она используется, файлы сертификатов, использующие такой встроенный ключ, должны быть настроены после сертификатов, использующих отдельный файл ключа.

В качестве альтернативы хранению закрытых ключей в файлах, может быть использован идентификатор ключа для идентификации закрытого ключа, хранящегося в токене. В настоящее время только PKCS#11 URI распознаются как идентификаторы закрытых ключей и могут быть использованы в сочетании с OpenSSL pkcs11 модулем.

# To use a private key from a PEM-encoded file:
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"
# To use a private key from a PKCS#11 token:
SSLCertificateKeyFile "pkcs11:token=My%20Token%20Name;id=45"

Директива SSLCipherSuite

SSLCipherSuite [protocol] cipher-spec

SSLCipherSuite DEFAULT (depends on OpenSSL version)

Эта сложная директива использует строку cipher-spec, разделённую двоеточием, содержащую спецификации шифров OpenSSL для настройки набора шифров, который клиент может согласовать в фазе рукопожатия SSL. Необязательный спецификатор протокола может настроить набор шифров для определённой версии SSL. Возможные значения включают "SSL" для всех протоколов SSL до и включая TLSv1.2.

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

Если библиотека SSL поддерживает TLSv1.3 (OpenSSL 1.1.1 и более поздние версии), можно использовать спецификатор протокола "TLSv1.3" для настройки наборов шифров для этого протокола. Поскольку TLSv1.3 не поддерживает переподключения, указание шифров для него в контексте директории запрещено.

Список имён шифров TLSv1.3 см. в документации OpenSSL.

Спецификация SSL-шифра в cipher-spec состоит из 4 основных атрибутов и нескольких дополнительных:

• Алгоритм обмена ключами:
  RSA, Diffie-Hellman, Эллиптическая кривая Diffie-Hellman, Secure Remote Password
• Алгоритм аутентификации:
  RSA, Diffie-Hellman, DSS, ECDSA или none.
• Алгоритм шифрования:
  AES, DES, Triple-DES, RC4, RC2, IDEA и т.д.
• Алгоритм MAC-хеширования:
  MD5, SHA или SHA1, SHA256, SHA384.

SSL-шифр также может быть экспортным шифром. Шифры SSLv2 больше не поддерживаются. Для указания используемых шифров можно указать все шифры по одному или использовать псевдонимы для указания предпочтения и порядка шифров (см. Таблица 1). Фактически доступные шифры и псевдонимы зависят от используемой версии OpenSSL. Более новые версии OpenSSL могут включать дополнительные шифры.

Теперь, где это становится интересным, заключается в том, что их можно объединить для указания порядка и шифров, которые вы хотите использовать. Для ускорения этого процесса также существуют псевдонимы (SSLv3, TLSv1, EXP, LOW, MEDIUM, HIGH) для определённых групп шифров. Эти метки могут быть объединены с префиксами для формирования cipher-spec. Доступные префиксы:

• none: добавить шифр в список
• +: переместить соответствующие шифры в текущую позицию в списке
• -: удалить шифр из списка (его можно добавить позже)
• !: полностью удалить шифр из списка (его нельзя добавить позже)

Более простой способ посмотреть на всё это - использовать команду ``openssl ciphers -v'', которая предоставляет удобный способ последовательного создания корректной строки cipher-spec. Строка cipher-spec по умолчанию зависит от версии используемых библиотек OpenSSL. Предположим, что это ``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'', что означает следующее: поместить RC4-SHA и AES128-SHA в начало. Мы делаем это, потому что эти шифры предлагают хороший баланс между скоростью и безопасностью. Затем включите шифры высокой и средней безопасности. Наконец, удалите все шифры, которые не выполняют аутентификацию, т.е. для SSL анонимные шифры Diffie-Hellman, а также все шифры, использующие MD5 в качестве алгоритма хеширования, потому что он оказался недостаточным.

$ openssl ciphers -v 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
...                     ...               ...     ...           ...
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1

Полный список конкретных RSA и DH шифров для SSL представлен в таблице 2.

SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW

Направление SSLCompression

SSLCompression on|off

SSLCompression off

Данное направление позволяет включить сжатие на уровне SSL.

Направление SSLCryptoDevice

SSLCryptoDevice engine

SSLCryptoDevice builtin

Данное направление позволяет использовать плату криптографического ускорителя аппаратного обеспечения для разгрузки части накладных расходов обработки SSL. Это направление может быть использовано только в том случае, если набор инструментов SSL был скомпилирован с поддержкой "engine"; OpenSSL 0.9.7 и более поздние версии имеют поддержку "engine" по умолчанию, для использования OpenSSL 0.9.6 необходимо использовать отдельные релизы "-engine".

Чтобы узнать имена поддерживаемых модулей, выполните команду "openssl engine".

# For a Broadcom accelerator:
SSLCryptoDevice ubsec

Направление SSLEngine

SSLEngine on|off|optional

SSLEngine off

Данное направление переключает использование двигателя протокола SSL/TLS. Это должно быть использовано внутри раздела <VirtualHost> для включения SSL/TLS для данного виртуального хоста. По умолчанию двигатель протокола SSL/TLS отключен как для основного сервера, так и для всех настроенных виртуальных хостов.

<VirtualHost _default_:443>
SSLEngine on
#...
</VirtualHost>

В Apache 2.1 и более поздних версиях, SSLEngine может быть установлено в optional. Это включает поддержку RFC 2817, обновления до TLS в рамках HTTP/1.1. В настоящее время ни один браузер не поддерживает RFC 2817.

Направление SSLFIPS

SSLFIPS on|off

SSLFIPS off

Это направление включает использование флага FIPS_mode библиотеки SSL. Оно должно быть установлено в глобальном контексте сервера и не может быть сконфигурировано с конфликтующими настройками (SSLFIPS включено, затем SSLFIPS выключено или аналогично). Режим применяется ко всем операциям библиотеки SSL.

Если httpd был скомпилирован с библиотекой SSL, которая не поддерживает флаг FIPS_mode, SSLFIPS on завершится с ошибкой. Обратитесь к документу политики безопасности FIPS 140-2 поставщика библиотек SSL для получения конкретных требований к использованию mod_ssl в режиме FIPS 140-2; обратите внимание, что сам mod_ssl не валидируется, но может быть описан как использующий валидированный криптографический модуль FIPS 140-2, когда все компоненты собраны и работают в соответствии с указаниями, налагаемыми соответствующей политикой безопасности.

Направление SSLHonorCipherOrder

SSLHonorCipherOrder on|off

SSLHonorCipherOrder off

При выборе шифра во время рукопожатия SSLv3 или TLSv1 обычно используется предпочтение клиента. Если данное направление включено, вместо этого будет использоваться предпочтение сервера.

SSLHonorCipherOrder on

Направление SSLInsecureRenegotiation

SSLInsecureRenegotiation on|off

SSLInsecureRenegotiation off

Как изначально было указано, все версии протоколов SSL и TLS (вплоть до TLS/1.2) были уязвимы для атаки «человек посередине» (CVE-2009-3555) во время возобновления. Эта уязвимость позволяла злоумышленнику «предпослать» выбранный открытый текст к запросу HTTP, как видно веб-серверу. Был разработан расширение протокола, которое исправило эту уязвимость, если она поддерживается как клиентом, так и сервером.

Если mod_ssl связан с OpenSSL версии 0.9.8m или более поздней, по умолчанию возобновление поддерживается только с клиентами, поддерживающими новое расширение протокола. Если это направление включено, возобновление будет разрешено для старых (неисправленных) клиентов, хотя и небезопасно.

SSLInsecureRenegotiation on

Переменная среды SSL_SECURE_RENEG может быть использована из скрипта SSI или CGI для определения того, поддерживается ли безопасное возобновление для данного соединения SSL.

Направление SSLOCSPDefaultResponder

SSLOCSPDefaultResponder uri

Этот параметр устанавливает ответчика OCSP по умолчанию. Если SSLOCSPOverrideResponder не включен, указанный URI будет использоваться только в том случае, если в проверяемом сертификате не указан URI ответчика.

Направление SSLOCSPEnable

SSLOCSPEnable on|leaf|off

SSLOCSPEnable off

Этот параметр включает валидацию OCSP цепочки сертификатов клиента. Если этот параметр включен, сертификаты в цепочке сертификатов клиента будут проверены на соответствие ответчику OCSP после завершения обычной проверки (включая проверки CRL). В режиме 'leaf' будет проверен только сам сертификат клиента.

Используемый ответчик OCSP извлекается либо из самого сертификата, либо определяется конфигурацией; см. SSLOCSPDefaultResponder и SSLOCSPOverrideResponder направления.

SSLVerifyClient on
SSLOCSPEnable on
SSLOCSPDefaultResponder "http://responder.example.com:8888/responder"
SSLOCSPOverrideResponder on

Направление SSLOCSPNoverify

SSLOCSPNoverify on|off

SSLOCSPNoverify off

Пропускается проверка сертификатов ответчика OCSP, в основном полезна при тестировании сервера OCSP.

Направление SSLOCSPOverrideResponder

SSLOCSPOverrideResponder on|off

SSLOCSPOverrideResponder off

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

Направление SSLOCSPProxyURL

SSLOCSPProxyURL url

Этот параметр позволяет установить URL HTTP-прокси, который должен использоваться для всех запросов к ответчикам OCSP.

Направление SSLOCSPResponderCertificateFile

SSLOCSPResponderCertificateFile file

Это предоставляет список доверенных сертификатов ответчиков OCSP, используемых во время валидации сертификатов ответчиков OCSP. Предоставленные сертификаты неявно доверяются без дополнительной проверки. Обычно это используется в тех случаях, когда сертификат ответчика OCSP является самоподписанным или отсутствует в ответе OCSP.

Директива SSLOCSPResponderTimeout

SSLOCSPResponderTimeout seconds

SSLOCSPResponderTimeout 10

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

Директива SSLOCSPResponseMaxAge

SSLOCSPResponseMaxAge seconds

SSLOCSPResponseMaxAge -1

Этот параметр устанавливает максимальный допустимый срок действия ("свежесть") ответов OCSP. Значение по умолчанию (-1) не накладывает ограничения на максимальный срок действия, что означает, что ответы OCSP считаются действительными, пока их поле nextUpdate находится в будущем.

Директива SSLOCSPResponseTimeSkew

SSLOCSPResponseTimeSkew seconds

SSLOCSPResponseTimeSkew 300

Этот параметр устанавливает максимальный допустимый сдвиг во времени для ответов OCSP (при проверке их полей thisUpdate и nextUpdate).

Директива SSLOCSPUseRequestNonce

SSLOCSPUseRequestNonce on|off

SSLOCSPUseRequestNonce on

Этот параметр определяет, должны ли запросы к отвечающим на OCSP запросы содержать nonce или нет. По умолчанию nonce запроса всегда используется и проверяется с nonce ответа. Если отвечающий не использует nonce (например, Microsoft OCSP Responder), этот параметр необходимо отключить off.

Директива SSLOpenSSLConfCmd

SSLOpenSSLConfCmd command-name command-value

Эта директива предоставляет доступ к API OpenSSL SSL_CONF модулю mod_ssl, позволяя гибко настраивать параметры OpenSSL без необходимости реализации дополнительных mod_ssl директив при добавлении новых функций в OpenSSL.

Набор доступных SSLOpenSSLConfCmd команд зависит от используемой версии OpenSSL для mod_ssl (требуется не менее версии 1.0.2). Список поддерживаемых имен команд см. в разделе Поддерживаемые команды конфигурационного файла в руководстве OpenSSL SSL_CONF_cmd(3).

Некоторые из SSLOpenSSLConfCmd команд могут использоваться в качестве альтернативы существующим директивам (таким как SSLCipherSuite или SSLProtocol), хотя следует отметить, что синтаксис/допустимые значения параметров иногда могут отличаться.

SSLOpenSSLConfCmd Options -SessionTicket,ServerPreference
SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1
SSLOpenSSLConfCmd ServerInfoFile "/usr/local/apache2/conf/server-info.pem"
SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2"
SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256

Директива SSLOptions

SSLOptions [+|-]option ...

Эта директива может использоваться для управления различными параметрами во время выполнения на уровне каталога. Обычно, если несколько SSLOptions могут применяться к каталогу, то используется только наиболее конкретный; параметры не объединяются. Однако, если все параметры в директиве SSLOptions предваряются знаком плюс (+) или минус (-), параметры объединяются. Любые параметры, предваряемые знаком +, добавляются к текущим параметрам, а параметры, предваряемые знаком -, удаляются из текущих параметров.

Доступные параметры:

• StdEnvVars

  При включении этой опции создается стандартный набор переменных окружения CGI/SSI, связанных с SSL. По умолчанию эта опция отключена для повышения производительности, так как процесс извлечения информации является достаточно дорогостоящим. Поэтому обычно эта опция включается только для запросов CGI и SSI.

• ExportCertData

  При включении этой опции создаются дополнительные переменные окружения CGI/SSI: SSL_SERVER_CERT, SSL_CLIENT_CERT и SSL_CLIENT_CERT_CHAIN_n (где n = 0,1,2,..). Эти переменные содержат PEM-закодированные сертификаты X.509 сервера и клиента для текущего HTTPS-соединения и могут использоваться сценариями CGI для более глубокой проверки сертификатов. Дополнительно предоставляются все другие сертификаты цепочки сертификатов клиента. Это немного увеличивает окружение, поэтому необходимо использовать эту опцию по мере необходимости.

• FakeBasicAuth

  При включении этой опции, Субъект Идентификатор (DN) Сертификата Клиента X509 преобразуется в имя пользователя HTTP Basic Authorization. Это означает, что стандартные методы аутентификации Apache могут использоваться для управления доступом. Имя пользователя - это просто Субъект сертификата X.509 клиента (может быть определен, запустив команду OpenSSL openssl x509: openssl x509 -noout -subject -incertificate.crt). Обратите внимание, что пароль не запрашивается у пользователя. Каждый элемент в файле пользователя требует этого пароля: ``xxj31ZMTZzkVA'', который является DES-зашифрованной версией слова `password'. Те, кто использует шифрование на основе MD5 (например, под FreeBSD или BSD/OS и т.д.), должны использовать следующий хеш MD5 того же слова: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.

  Обратите внимание, что директива AuthBasicFake внутри mod_auth_basic может использоваться как более общий механизм для имитации аутентификации Basic, предоставляя контроль над структурой как имени пользователя, так и пароля.

• StrictRequire

  Это принудительно запрещает доступ, когда SSLRequireSSL или SSLRequire успешно определили, что доступ должен быть запрещен. Обычно по умолчанию, в случае использования директивы ``Satisfy any'' и прохождения других ограничений доступа, отказ в доступе из-за SSLRequireSSL или SSLRequire перекрывается (так как механизм Apache Satisfy должен работать именно так.) Но для строгого ограничения доступа можно использовать SSLRequireSSL и/или SSLRequire в сочетании с ``SSLOptions +StrictRequire''. Тогда дополнительная ``Satisfy Any'' не будет иметь шансов, как только mod_ssl решит отказать в доступе.

• OptRenegotiate

  Это включает оптимизированную обработку повторного установления соединения SSL при использовании SSL директив в контексте каталога. По умолчанию включен строгий режим, где каждое переконфигурирование параметров SSL на уровне каталога вызывает полный обмен SSL. При использовании этой опции mod_ssl пытается избежать ненужных обменов, выполняя более точные (но безопасные) проверки параметров. Тем не менее, эти точные проверки иногда могут не соответствовать ожиданиям пользователя, поэтому включайте эту опцию только на уровне каталога.

• LegacyDNStringFormat

  Этот параметр влияет на то, как форматируются значения переменных SSL_{CLIENT,SERVER}_{I,S}_DN. С версии 2.3.11 Apache HTTPD по умолчанию использует совместимый с RFC 2253 формат. Он использует запятые в качестве разделителей между атрибутами, допускает использование символов, не входящих в ASCII (которые преобразуются в UTF8), экранирует различные специальные символы обратными слешами и сортирует атрибуты, помещая атрибут "C" последним.

  Если LegacyDNStringFormat установлен, будет использоваться старый формат, который сортирует атрибут "C" первым, использует косые черты в качестве разделителей и не обрабатывает символы, не входящие в ASCII, и специальные символы каким-либо последовательным способом.

SSLOptions +FakeBasicAuth -StrictRequire
<Files ~ "\.(cgi|shtml)$">
    SSLOptions +StdEnvVars -ExportCertData
</Files>

Директива SSLPassPhraseDialog

SSLPassPhraseDialog type

SSLPassPhraseDialog builtin

При запуске Apache ему необходимо прочитать различные сертификаты (см. SSLCertificateFile) и закрытые ключи (см. SSLCertificateKeyFile) виртуальных серверов с включенным SSL. Поскольку по соображениям безопасности файлы закрытых ключей обычно зашифрованы, mod_ssl должен запросить у администратора фразу пароля для их расшифровки. Этот запрос можно выполнить двумя способами, которые можно настроить с помощью параметра type:

• builtin

  Это значение по умолчанию, при котором интерактивное диалоговое окно терминала появляется при запуске, сразу перед тем, как Apache отсоединится от терминала. Здесь администратор должен вручную ввести фразу пароля для каждого зашифрованного файла закрытого ключа. Поскольку может быть настроено множество виртуальных хостов с SSL, используется следующая схема повторного использования для минимизации диалоговых окон: Когда файл закрытого ключа зашифрован, все известные фразы паролей (в начале их, конечно, нет) проверяются. Если одна из этих фраз паролей успешно расшифрует ключ, для этого файла не появляется диалоговое окно. Если ни одна из фраз паролей не подошла, на терминале запрашивается другая фраза пароля и запоминается для следующего раунда (где она, возможно, может быть повторно использована).

  Эта схема позволяет mod_ssl быть максимально гибким (поскольку для N зашифрованных файлов закрытого ключа вы можете использовать N различных фраз паролей — но тогда вам, конечно, придется ввести их все), при этом минимизируя диалоговые окна терминала (то есть, когда вы используете одну фразу пароля для всех N файлов закрытого ключа, эта фраза пароля запрашивается только один раз).

• |/path/to/program [args...]

  Этот режим позволяет использовать внешнюю программу, которая действует как канал связи с определённым устройством ввода-вывода; программе отправляется стандартный текст запроса, используемый для режима builtin в stdin, и ожидается, что она запишет строки пароля в stdout. Если требуется несколько паролей (или введён неверный пароль), дополнительно текст запроса будет отправлен после того, как будет возвращён первый пароль, и тогда должны быть возвращены дополнительные пароли.

• exec:/path/to/program

  Здесь настраивается внешняя программа, которая вызывается при запуске для каждого зашифрованного файла закрытого ключа. Она вызывается с двумя аргументами (первый имеет вид ``servername:portnumber'', второй — либо ``RSA'', ``DSA'', ``ECC'', либо целочисленный индекс, начинающийся с 3, если настроено более трёх ключей), которые указывают, для какого сервера и алгоритма она должна напечатать соответствующую фразу пароля в stdout. В версиях 2.4.8 (не выпущенных) и 2.4.9 она вызывается с одним аргументом, строкой вида ``servername:portnumber:index'' (где index — целое число с нулевой базой), указывающей сервер, TCP-порт и номер сертификата. Цель состоит в том, чтобы эта внешняя программа сначала выполнила проверки безопасности, чтобы убедиться, что система не скомпрометирована злоумышленником, и только после успешного прохождения этих проверок она предоставляет фразу пароля.

  Обе эти проверки безопасности, и способ определения фразы пароля, могут быть такими сложными, как вам угодно. Mod_ssl просто определяет интерфейс: исполняемую программу, которая предоставляет фразу пароля в stdout. Ничего больше и ничего меньше! Поэтому, если вы действительно обеспокоены безопасностью, вот ваш интерфейс. Всё остальное должно остаться упражнением для администратора, поскольку местные требования безопасности сильно различаются.

  Вышеупомянутый алгоритм повторного использования используется и здесь. Другими словами: внешняя программа вызывается только один раз для каждой уникальной фразы пароля.

SSLPassPhraseDialog "exec:/usr/local/apache/sbin/pp-filter"

Директива SSLProtocol

SSLProtocol [+|-]protocol ...

SSLProtocol all -SSLv3 (up to 2.4.16: all)

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

Доступные (регистронезависимые) протоколы:

• SSLv3

  Протокол Secure Sockets Layer (SSL) версии 3.0 от Netscape Corporation. Он является преемником SSLv2 и предшественником TLSv1, но устарел в RFC 7568.

• TLSv1

  Протокол Transport Layer Security (TLS) версии 1.0. Он является преемником SSLv3 и определен в RFC 2246. Он поддерживается практически всеми клиентами.

• TLSv1.1 (при использовании OpenSSL 1.0.1 и более поздних версий)

  Пересмотренный протокол TLS 1.0, как определено в RFC 4346.

• TLSv1.2 (при использовании OpenSSL 1.0.1 и более поздних версий)

  Пересмотренный протокол TLS 1.1, как определено в RFC 5246.

• TLSv1.3 (при использовании OpenSSL 1.1.1 и более поздних версий)

  Новая версия протокола TLS, как определено в RFC 8446.

• all

  Это сокращение для ``+SSLv3 +TLSv1'' или — при использовании OpenSSL 1.0.1 и более поздних версий — ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2'', соответственно (за исключением версий OpenSSL, скомпилированных с опцией конфигурации «no-ssl3», где all не включает +SSLv3).

SSLProtocol TLSv1

Директива SSLProxyCACertificateFile

SSLProxyCACertificateFile file-path

Данная директива устанавливает объединённый файл, где вы можете собрать сертификаты центров сертификации (CA), с которыми взаимодействуют ваши удаленные серверы. Они используются для проверки подлинности удаленного сервера. Такой файл представляет собой простое объединение различных файлов сертификатов в формате PEM, в порядке приоритета. Его можно использовать как альтернативу и/или дополнение к SSLProxyCACertificatePath.

SSLProxyCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt"

Директива SSLProxyCACertificatePath

SSLProxyCACertificatePath directory-path

Данная директива устанавливает директорию, где хранятся сертификаты центров сертификации (CA), с которыми взаимодействуют ваши удаленные серверы. Они используются для проверки подлинности сертификата удалённого сервера в процессе проверки подлинности удалённого сервера.

Файлы в этой директории должны быть в формате PEM и к ним осуществляется доступ по хэшированным именам файлов. Поэтому обычно вы не можете просто поместить файлы сертификатов в эту директорию: вам также необходимо создать символические ссылки с именами hash-value.N. И всегда нужно убедиться, что эта директория содержит соответствующие символические ссылки.

SSLProxyCACertificatePath "/usr/local/apache2/conf/ssl.crt/"

Директива SSLProxyCARevocationCheck

SSLProxyCARevocationCheck chain|leaf|none

SSLProxyCARevocationCheck none

Включает проверку списков отзыва сертификатов (CRL) для удаленных серверов. Необходимо настроить по крайней мере один из SSLProxyCARevocationFile или SSLProxyCARevocationPath . При установке в chain (рекомендуемое значение), проверки CRL применяются ко всем сертификатам в цепочке, а при установке в leaf проверки ограничиваются сертификатом конечного узла.

SSLProxyCARevocationCheck chain

Директива SSLProxyCARevocationFile

SSLProxyCARevocationFile file-path

Данная директива устанавливает общий файл, в котором можно собрать списки отозванных сертификатов (CRL) центров сертификации (CA), с которыми взаимодействуют удаленные серверы. Они используются для аутентификации удаленных серверов. Такой файл представляет собой просто конкатенацию различных PEM-кодированных файлов CRL в порядке приоритета. Это можно использовать альтернативно и/или дополнительно к SSLProxyCARevocationPath.

SSLProxyCARevocationFile "/usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl"

Директива SSLProxyCARevocationPath

SSLProxyCARevocationPath directory-path

Эта директива задает директорию, в которой хранятся списки отозванных сертификатов (CRL) центров сертификации (CA), с которыми взаимодействуют удаленные серверы. Они используются для отзыва сертификата удаленного сервера при аутентификации удаленного сервера.

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

SSLProxyCARevocationPath "/usr/local/apache2/conf/ssl.crl/"

Директива SSLProxyCheckPeerCN

SSLProxyCheckPeerCN on|off

SSLProxyCheckPeerCN on

Эта директива устанавливает, сравнивается ли поле CN сертификата удалённого сервера с именем хоста запрошенного URL. Если они не совпадают, отправляется код состояния 502 (Bad Gateway). SSLProxyCheckPeerCN устарела и заменена на SSLProxyCheckPeerName в релизе 2.4.5 и более поздних версиях.

Во всех релизах с 2.4.5 по 2.4.20 установка SSLProxyCheckPeerName off было достаточно для активации этого поведения (поскольку значение SSLProxyCheckPeerCN по умолчанию было on). В этих релизах обе директивы должны быть установлены в off для полного отключения проверки имени сертификата удалённого сервера. Многие пользователи сообщали, что это очень запутанно.

Начиная с релиза 2.4.21, все конфигурации, которые включают любой из SSLProxyCheckPeerName или SSLProxyCheckPeerCN вариантов, будут использовать новое поведение SSLProxyCheckPeerName, а все конфигурации, которые отключают любой из SSLProxyCheckPeerName или SSLProxyCheckPeerCN вариантов, подавят всю проверку имени сертификата удалённого сервера. Только следующие конфигурации будут вызывать проверку имени сертификата удалённого сервера по старой схеме в 2.4.21 и более поздних релизах;

SSLProxyCheckPeerCN on
SSLProxyCheckPeerName off

Директива SSLProxyCheckPeerExpire

SSLProxyCheckPeerExpire on|off

SSLProxyCheckPeerExpire on

Эта директива устанавливает, проверяется ли срок действия сертификата удалённого сервера. Если проверка не пройдена, отправляется код состояния 502 (Bad Gateway).

SSLProxyCheckPeerExpire on

Директива SSLProxyCheckPeerName

SSLProxyCheckPeerName on|off

SSLProxyCheckPeerName on

Данная директива настраивает проверку имени хоста для сертификатов серверов, когда mod_ssl выступает в роли SSL-клиента. Проверка пройдёт, если имя хоста из URI запроса соответствует одному из атрибутов CN предмета сертификата или соответствует расширению subjectAltName. Если проверка не пройдена, запрос SSL прерывается, и возвращается код состояния 502 (Bad Gateway).

Поддерживается подстановка подстановочных знаков в некоторых случаях: запись типа dNSName в subjectAltName или атрибуты CN, начинающиеся с *., будут соответствовать любому имени хоста с тем же количеством элементов имени и тем же суффиксом. Например, *.example.org будет соответствовать foo.example.org, но не будет соответствовать foo.bar.example.org, так как количество элементов в соответствующих именах хостов отличается.

Эта функция была введена в версии 2.4.5 и заменила поведение директивы SSLProxyCheckPeerCN, которая проверяла только точное значение первого атрибута CN по отношению к имени хоста. Однако многие пользователи были сбиты с толку поведением использования этих директив по отдельности, поэтому взаимное поведение директив SSLProxyCheckPeerName и SSLProxyCheckPeerCN было улучшено в релизе 2.4.21. См. описание директивы SSLProxyCheckPeerCN для получения информации об исходном поведении и подробностей этих улучшений.

Директива SSLProxyCipherSuite

SSLProxyCipherSuite [protocol] cipher-spec

SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP

Эквивалентно SSLCipherSuite, но для прокси-соединения. Дополнительную информацию см. в SSLCipherSuite.

Директива SSLProxyEngine

SSLProxyEngine on|off

SSLProxyEngine off

Эта директива включает или отключает использование модуля SSL/TLS для прокси. Обычно она используется внутри раздела <VirtualHost> для включения SSL/TLS для использования прокси в конкретном виртуальном хосте. По умолчанию модуль SSL/TLS отключен для прокси как для основного сервера, так и для всех настроенных виртуальных хостов.

Обратите внимание, что директива SSLProxyEngine обычно не должна включаться в виртуальный хост, который будет действовать как прокси-сервер (используя директивы <Proxy> или ProxyRequests). SSLProxyEngine не требуется для включения прокси-сервера для перенаправления запросов SSL/TLS.

<VirtualHost _default_:443>
    SSLProxyEngine on
    #...
</VirtualHost>

Директива SSLProxyMachineCertificateChainFile

SSLProxyMachineCertificateChainFile filename

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

Этот указанный файл представляет собой просто конкатенацию различных PEM-кодированных файлов сертификатов. При запуске будет проверено каждый настроенный клиентский сертификат, и будет построена цепочка доверия.

SSLProxyMachineCertificateChainFile "/usr/local/apache2/conf/ssl.crt/proxyCA.pem"

Директива SSLProxyMachineCertificateFile

SSLProxyMachineCertificateFile filename

Данная директива задаёт один файл, в котором хранятся сертификаты и ключи, используемые для аутентификации прокси-сервера по отношению к удалённым серверам.

Указанный файл представляет собой просто конкатенацию различных файлов сертификатов в PEM-кодировке. Используйте эту директиву как альтернативу или дополнение к SSLProxyMachineCertificatePath. Указанный файл может содержать любое количество пар клиентского сертификата и связанного с ним закрытого ключа. Каждая пара может быть указана в порядке (сертификат, ключ) или (ключ, сертификат). Если файл включает в себя сертификат, не являющийся листом, или любую несовпадающую пару ключ-сертификат, при запуске будет выдано сообщение об ошибке конфигурации.

При запросе предоставления клиентского сертификата удалённым сервером, сервер должен предоставить список допустимых имён центров сертификации в запросе. Если такой список не предоставлен, mod_ssl будет использовать первый настроенный клиентский сертификат/ключ. Если список имён ЦС предоставлен, mod_ssl будет перебирать этот список и пытаться найти настроенный клиентский сертификат, выданный либо напрямую этим ЦС, либо косвенно через любое количество промежуточных сертификатов ЦС. Цепочка промежуточных сертификатов ЦС может быть построена из тех, что настроены с SSLProxyMachineCertificateChainFile. Затем первый соответствующий настроенный сертификат будет предоставлен в ответ на запрос.

Если список имён ЦС предоставлен удалённым сервером и не найдено соответствующего клиентского сертификата, mod_ssl не предоставит клиентский сертификат, что, скорее всего, приведёт к сбою рукопожатия SSL/TLS (в зависимости от конфигурации удалённого сервера).

SSLProxyMachineCertificateFile "/usr/local/apache2/conf/ssl.crt/proxy.pem"

Директива SSLProxyMachineCertificatePath

SSLProxyMachineCertificatePath directory

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

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

SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"

Директива SSLProxyProtocol

SSLProxyProtocol [+|-]protocol ...

SSLProxyProtocol all -SSLv3 (up to 2.4.16: all)

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

Для получения дополнительной информации см. SSLProtocol.

Директива SSLProxyVerify

SSLProxyVerify level

SSLProxyVerify none

Когда прокси настроен на пересылку запросов на удалённый SSL-сервер, эта директива позволяет настроить проверку сертификата удалённого сервера.

Доступны следующие уровни для уровня:

• none: сертификат удалённого сервера вообще не требуется
• optional: удалённый сервер может представить действительный сертификат
• require: удалённый сервер должен представить действительный сертификат
• optional_no_ca: удалённый сервер может представить действительный сертификат
  но он не обязательно должен быть (успешно) проверен.

На практике действительно интересны только уровни none и require, потому что уровень optional не работает со всеми серверами, а уровень optional_no_ca противоречит идее аутентификации (но может использоваться для создания тестовых страниц SSL и т.д.).

SSLProxyVerify require

Директива SSLProxyVerifyDepth

SSLProxyVerifyDepth number

SSLProxyVerifyDepth 1

Эта директива задаёт, насколько глубоко mod_ssl должен проводить проверку, прежде чем решить, что у удалённого сервера нет действительного сертификата.

Глубина фактически представляет собой максимальное количество промежуточных сертификатов ЦС, т.е. максимальное количество сертификатов ЦС, которые разрешено отслеживать при проверке сертификата удалённого сервера. Глубина 0 означает, что принимаются только самозаверенные сертификаты удалённого сервера, глубина по умолчанию 1 означает, что сертификат удалённого сервера может быть самозаверенным или должен быть подписан ЦС, который непосредственно известен серверу (т.е. сертификат ЦС находится в SSLProxyCACertificatePath) и т.д.

SSLProxyVerifyDepth 10

Директива SSLRandomSeed

SSLRandomSeed context source [bytes]

Эта настройка определяет один или несколько источников для инициализации генератора псевдослучайных чисел (PRNG) в OpenSSL при запуске (контекст — startup) и/или непосредственно перед установлением нового SSL-соединения (контекст — connect). Эта директива может быть использована только в глобальном контексте сервера, так как PRNG — это глобальный механизм.

Доступны следующие варианты источников:

• builtin

  Это всегда доступный встроенный источник инициализации. Его использование потребляет минимальное количество циклов процессора во время выполнения, поэтому его можно использовать всегда без недостатков. Источник, используемый для инициализации PRNG, содержит текущее время, идентификатор текущего процесса и случайный 128-байтовый фрагмент стека. Недостатком является то, что это не очень надёжный источник, и при запуске (где таблица результатов ещё недоступна) этот источник генерирует всего несколько байтов энтропии. Поэтому вы всегда должны использовать дополнительный источник инициализации, по крайней мере, на этапе запуска.

• file:/path/to/source

  Этот вариант использует внешний файл /path/to/source в качестве источника инициализации PRNG. Если указан параметр bytes, то в качестве энтропии используются только первые bytes байт файла (и bytes передаётся /path/to/source в качестве первого аргумента). Если bytes не указан, вся информация файла используется в качестве энтропии (и 0 передаётся /path/to/source в качестве первого аргумента). Используйте это, особенно при запуске, например, с имеющимся /dev/random и/или /dev/urandom устройствами (которые обычно существуют в современных Unix-подобных системах, таких как FreeBSD и Linux).

  Но будьте осторожны: Обычно /dev/random предоставляет только столько данных энтропии, сколько их у него есть. Например, если вы запрашиваете 512 байтов энтропии, но на устройстве доступно только 100 байтов, то могут произойти две вещи: в некоторых системах вы получите только 100 байтов, а в других чтение будет блокироваться до тех пор, пока не будет доступно достаточное количество байтов (что может занять много времени). В этом случае лучше использовать существующее /dev/urandom устройство, так как оно никогда не блокируется и фактически даёт запрошенное количество данных. Недостатком является то, что качество полученных данных может быть не самым лучшим.

• exec:/path/to/program

  Этот вариант использует внешний исполняемый файл /path/to/program в качестве источника инициализации PRNG. Если указан параметр bytes, то в качестве энтропии используются первые bytes байтов его stdout содержимого. Если bytes не указан, то вся информация, сгенерированная на stdout , используется в качестве энтропии. Используйте это только при запуске, если вам нужен очень надёжный источник инициализации с помощью внешней программы (например, как в примере выше с утилитой truerand из дистрибутива mod_ssl, которая основана на библиотеке AT&T truerand). Конечно, использование этого в контексте соединения слишком сильно замедляет сервер. Поэтому, как правило, следует избегать использования внешних программ в этом контексте.

• egd:/path/to/egd-socket (только Unix)

  Этот вариант использует Unix-сокет доменного типа внешнего демона сбора энтропии (EGD) (см. http://www.lothar.com/tech/crypto/) для инициализации PRNG. Используйте его, если на вашей платформе нет устройств для генерации случайных чисел.

SSLRandomSeed startup builtin
SSLRandomSeed startup "file:/dev/random"
SSLRandomSeed startup "file:/dev/urandom" 1024
SSLRandomSeed startup "exec:/usr/local/bin/truerand" 16
SSLRandomSeed connect builtin
SSLRandomSeed connect "file:/dev/random"
SSLRandomSeed connect "file:/dev/urandom" 1024

Директива SSLRenegBufferSize

SSLRenegBufferSize bytes

SSLRenegBufferSize 131072

Если для переподключения SSL требуется контекст на уровне расположения, например, при использовании SSLVerifyClient в блоке Directory или Location, то mod_ssl должен буферизовать тело HTTP-запроса в памяти до тех пор, пока не будет выполнено новое SSL-соединение. Эта директива позволяет установить объём памяти, который будет использоваться для этого буфера.

SSLRenegBufferSize 262144

Директива SSLRequire

SSLRequire expression

Эта директива задаёт общее требование доступа, которое должно быть выполнено для разрешения доступа. Это очень мощная директива, так как спецификация требования — произвольное логическое выражение, содержащее любое количество проверок доступа.

Выражение должно соответствовать следующему синтаксису (представленному в формате BNF):

expr     ::= "true" | "false"
           | "!" expr
           | expr "&&" expr
           | expr "||" expr
           | "(" expr ")"
           | comp

comp     ::= word "==" word | word "eq" word
           | word "!=" word | word "ne" word
           | word "<"  word | word "lt" word
           | word "<=" word | word "le" word
           | word ">"  word | word "gt" word
           | word ">=" word | word "ge" word
           | word "in" "{" wordlist "}"
           | word "in" "PeerExtList(" word ")"
           | word "=~" regex
           | word "!~" regex

wordlist ::= word
           | wordlist "," word

word     ::= digit
           | cstring
           | variable
           | function

digit    ::= [0-9]+
cstring  ::= "..."
variable ::= "%{" varname "}"
function ::= funcname "(" funcargs ")"

Для varname можно использовать любые переменные, описанные в Переменные среды. Для funcname доступные функции перечислены в документации ap_expr.

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

SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)-/                   \
            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd."          \
            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}    \
            and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5          \
            and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20       ) \
           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

Функция PeerExtList(object-ID) ожидает найти ноль или более экземпляров расширения сертификата X.509, идентифицированного указанным объектным идентификатором (OID), в сертификате клиента. Выражение оценивается как истинное, если левая часть строки точно совпадает со значением расширения, идентифицированного этим OID. (Если присутствует несколько расширений с одинаковым OID, по крайней мере, одно расширение должно соответствовать).

SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")

См. также

• Переменные окружения в Apache HTTP Server, для дополнительных примеров.
• Require expr
• Общий синтаксис выражений в Apache HTTP Server

Директива SSLRequireSSL

Эта директива запрещает доступ, если для текущего соединения не включено HTTP через SSL (т.е. HTTPS). Это очень полезно внутри виртуального хоста или каталогов, использующих SSL, для защиты от ошибок конфигурации, которые раскрывают защищённую информацию. При наличии этой директивы все запросы, не использующие SSL, будут отклоняться.

SSLRequireSSL

Директива SSLSessionCache

SSLSessionCache type

SSLSessionCache none

Эта директива настраивает тип хранения глобального/межпроцессного кеша SSL сессий. Этот кеш — необязательная функция, ускоряющая обработку параллельных запросов. Для запросов к одному и тому же процессу сервера (через HTTP keep-alive) OpenSSL уже кэширует информацию о SSL сессии локально. Но поскольку современные клиенты запрашивают встроенные изображения и другие данные через параллельные запросы (обычно до четырёх параллельных запросов), эти запросы обрабатываются разными предварительно разветвлёнными процессами сервера. Здесь межпроцессный кеш помогает избежать ненужных сеансов рукопожатия.

В настоящее время поддерживаются следующие пять типов хранения:

• none

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

• nonenotnull

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

• dbm:/path/to/datafile

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

• shmcb:/path/to/datafile[(размер)]

  Это использует высокопроизводительный циклический буфер (примерно размер байт) внутри сегмента общей памяти в ОЗУ (созданного с помощью /path/to/datafile) для синхронизации локальных кешей памяти OpenSSL процессов сервера. Это рекомендуемый кеш сессий. Для использования этого, убедитесь, что mod_socache_shmcb загружен.

• dc:UNIX:/path/to/socket

  Это использует библиотеки распределённого кеширования сессий distcache. Аргумент должен указать местоположение сервера или прокси-сервера, используемого с использованием синтаксиса адреса distcache; например, UNIX:/path/to/socket указывает сокет домена Unix (обычно локальный прокси-сервер dc_client); IP:server.example.com:9001 указывает IP-адрес. Для использования этого, убедитесь, что mod_socache_dc загружен.

SSLSessionCache "dbm:/usr/local/apache/logs/ssl_gcache_data"
SSLSessionCache "shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)"

Мьютекс ssl-cache используется для сериализации доступа к кешу сессий, чтобы предотвратить повреждение. Этот мьютекс можно настроить с помощью директивы Mutex.

Директива SSLSessionCacheTimeout

SSLSessionCacheTimeout seconds

SSLSessionCacheTimeout 300

Эта директива устанавливает время ожидания в секундах для информации, хранящейся в глобальном/межпроцессном кеше SSL сессий, локальном кеше памяти OpenSSL и для возобновлённых сессий с помощью возобновления сессии TLS (RFC 5077). Для тестирования его можно установить как 15, но в реальной жизни следует устанавливать значения побольше, например, 300.

SSLSessionCacheTimeout 600

Директива SSLSessionTicketKeyFile

SSLSessionTicketKeyFile file-path

Опционально настраивает секретный ключ для шифрования и расшифрования билетов TLS сессий, как определено в RFC 5077. В первую очередь подходит для кластеризованных сред, где информация о сессиях TLS должна быть распределена между несколькими узлами. Для установок httpd с одной инстанцией рекомендуется не настраивать файл ключа билета, а вместо этого полагаться на (случайные) ключи, сгенерированные mod_ssl при запуске.

Файл ключа билета должен содержать 48 байт случайных данных, предпочтительно созданных из источника с высокой энтропией. В системе на базе Unix файл ключа билета можно создать следующим образом:

dd if=/dev/random of=/path/to/file.tkey bs=1 count=48

Ключи билетов следует обновлять (заменять) регулярно, поскольку это единственный способ аннулировать существующий билет сессии — OpenSSL в настоящее время не позволяет указать ограничение для времени жизни билетов. Новый ключ билета используется только после перезапуска веб-сервера. Все существующие билеты сессии становятся недействительными после перезапуска.

Директива SSLSessionTickets

SSLSessionTickets on|off

SSLSessionTickets on

Эта директива позволяет включить или отключить использование билетов TLS сессий (RFC 5077).

Директива SSLSRPUnknownUserSeed

SSLSRPUnknownUserSeed secret-string

Эта директива устанавливает seed, используемый для подделки параметров пользователя SRP для неизвестных пользователей, чтобы избежать утечки информации о том, существует ли данный пользователь. Укажите секретную строку. Если эта директива не используется, Apache вернёт клиенту предупреждение UNKNOWN_PSK_IDENTITY, если клиент укажет неизвестное имя пользователя.

SSLSRPUnknownUserSeed "secret"

Директива SSLSRPVerifierFile

SSLSRPVerifierFile file-path

Эта директива включает TLS-SRP и устанавливает путь к файлу валидатора OpenSSL SRP (Secure Remote Password), содержащему имена пользователей TLS-SRP, валидаторы, соли и параметры группы.

SSLSRPVerifierFile "/path/to/file.srpv"

Файл валидатора можно создать с помощью утилиты командной строки openssl:

openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username

Значение, указанное с необязательным параметром -userinfo доступно в переменной окружения запроса SSL_SRP_USERINFO.

Директива SSLStaplingCache

SSLStaplingCache type

Настраивает кеш, используемый для хранения ответов OCSP, которые включаются в TLS рукопожатие, если SSLUseStapling включено. Настройка кеша обязательна для OCSP stapling. За исключением none и nonenotnull, поддерживаются те же типы хранения, что и с SSLSessionCache.

Директива SSLStaplingErrorCacheTimeout

SSLStaplingErrorCacheTimeout 600

Устанавливает время ожидания в секундах до истечения срока действия недействительных ответов в кеше OCSP stapling (настроенном с помощью SSLStaplingCache). Чтобы установить время ожидания кеша для действительных ответов, см. SSLStaplingStandardCacheTimeout.

Директива SSLStaplingFakeTryLater

SSLStaplingFakeTryLater on

При включении и при неудаче запроса к отвечающему на OCSP для целей stapling, mod_ssl сгенерирует ответ «попробуйте позже» для клиента. Действительно только если SSLStaplingReturnResponderErrors также включено.

Директива SSLStaplingForceURL

SSLStaplingForceURL uri

Данная директива переопределяет URI ответчика OCSP, полученного из расширения authorityInfoAccess (AIA) сертификата. Одно из потенциальных применений — использование прокси для получения запросов OCSP.

Директива SSLStaplingResponderTimeout

SSLStaplingResponderTimeout seconds

SSLStaplingResponderTimeout 10

Этот параметр устанавливает таймаут для запросов к ответчикам OCSP, когда SSLUseStapling включен, и mod_ssl запрашивает ответчика для целей OCSP стаплирования.

Директива SSLStaplingResponseMaxAge

SSLStaplingResponseMaxAge seconds

SSLStaplingResponseMaxAge -1

Этот параметр устанавливает максимальный допустимый срок жизни («свежесть») при рассмотрении ответов OCSP для целей стаплирования, т.е. когда SSLUseStapling включён. Значение по умолчанию (-1) не накладывает максимального срока жизни, что означает, что ответы OCSP считаются действительными, пока их поле nextUpdate находится в будущем.

Директива SSLStaplingResponseTimeSkew

SSLStaplingResponseTimeSkew seconds

SSLStaplingResponseTimeSkew 300

Этот параметр устанавливает максимальное допустимое смещение времени при проверке mod_ssl полей thisUpdate и nextUpdate ответов OCSP, которые включаются в TLS-рукопожатие (OCSP стаплирование). Применимо только если SSLUseStapling включен.

Директива SSLStaplingReturnResponderErrors

SSLStaplingReturnResponderErrors on|off

SSLStaplingReturnResponderErrors on

При включении mod_ssl передаст клиенту ответы от неудачных запросов OCSP, связанных со стаплированием (например, ответы с общим статусом, отличным от «успешный», ответы с состоянием сертификата, отличным от «хороший», просроченные ответы и т. д.). Если установлено значение off, в TLS-рукопожатие будут включены только ответы, указывающие на статус сертификата «хороший».

Директива SSLStaplingStandardCacheTimeout

SSLStaplingStandardCacheTimeout seconds

SSLStaplingStandardCacheTimeout 3600

Устанавливает таймаут в секундах, прежде чем ответы в кэше OCSP стаплирования (настроенном через SSLStaplingCache) истекут. Эта директива применяется к действительным ответам, в то время как SSLStaplingErrorCacheTimeout используется для управления таймаутом для недопустимых/недоступных ответов.

Директива SSLStrictSNIVHostCheck

SSLStrictSNIVHostCheck on|off

SSLStrictSNIVHostCheck off

Данная директива устанавливает, разрешено ли клиентам без SNI обращаться к виртуальному хосту по имени. Если значение установлено в on в виртуальном хосте по умолчанию, клиентам, не поддерживающим SNI, не будет разрешен доступ к любому виртуальному хосту, относящемуся к данной комбинации IP/порта. Если значение установлено в on в любом другом виртуальном хосте, клиентам, не поддерживающим SNI, не будет разрешен доступ к данному виртуальному хосту.

SSLStrictSNIVHostCheck on

Директива SSLUserName

SSLUserName varname

Эта директива устанавливает поле «пользователь» в объекте запроса Apache. Это используется нижележащими модулями для идентификации пользователя с помощью строковой переменной. В частности, это может привести к установке переменной среды REMOTE_USER. Имя переменной varname может быть любой из переменных среды SSL.

Обратите внимание, что данная директива не имеет эффекта, если используется параметр FakeBasicAuth (см. SSLOptions).

SSLUserName SSL_CLIENT_S_DN_CN

Директива SSLUseStapling

SSLUseStapling on|off

SSLUseStapling off

Этот параметр включает OCSP стаплирование, как определено расширением «Certificate Status Request» TLS, указанным в RFC 6066. При включении (и запросе клиентом) mod_ssl включит в TLS-рукопожатие ответ OCSP для собственного сертификата. Настройка SSLStaplingCache является необходимым условием для включения OCSP стаплирования.

OCSP стаплирование освобождает клиента от запроса ответчика OCSP самостоятельно, но следует отметить, что согласно спецификации RFC 6066, ответ сервера CertificateStatus может содержать только один ответ OCSP для одного сертификата. Для серверных сертификатов с промежуточными сертификатами CA в цепочке (типичный случай в наши дни) стаплирование в текущей реализации, следовательно, лишь частично достигает заявленной цели «экономии раундов запросов и ресурсов» — см. также RFC 6961 (Расширение TLS Multiple Certificate Status).

Когда OCSP стаплирование включено, используется мьютекс ssl-stapling для управления доступом к кэшу OCSP стаплирования, чтобы предотвратить повреждение, и используется мьютекс sss-stapling-refresh для управления обновлениями ответов OCSP. Эти мьютексы можно настроить с помощью директивы Mutex.

Директива SSLVerifyClient

SSLVerifyClient level

SSLVerifyClient none

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

Доступны следующие уровни для level:

• none: сертификат клиента не требуется вообще
• optional: клиент может предоставить действительный сертификат
• require: клиент должен предоставить действительный сертификат
• optional_no_ca: клиент может предоставить действительный сертификат
  но он не обязательно должен быть (успешно) проверен. Этот параметр нельзя использовать для аутентификации клиента.

SSLVerifyClient require

Директива SSLVerifyDepth

SSLVerifyDepth number

SSLVerifyDepth 1

Эта директива задаёт, насколько глубоко mod_ssl должен проверять сертификат, прежде чем принять решение о том, что у клиента недействительный сертификат. Обратите внимание, что эта директива может использоваться как в контексте всего сервера, так и в контексте каждой директории. В контексте сервера она применяется к процессу проверки клиента, используемому в стандартном рукопожатии SSL при установлении соединения. В контексте директории она вынуждает переподключение SSL с переконфигурированной глубиной проверки клиента после обработки запроса HTTP, но перед отправкой ответа HTTP.

Глубина фактически является максимальным количеством промежуточных сертификатов выдачи (т.е. количество сертификатов CA, которое максимально разрешено проверять при проверке сертификата клиента). Глубина 0 означает, что принимаются только самозаверенные сертификаты клиента, глубина 1 по умолчанию означает, что сертификат клиента может быть самозаверенным или должен быть подписан CA, который напрямую известен серверу (т.е. сертификат CA находится в SSLCACertificatePath) и т.д.

SSLVerifyDepth 10