Spec-Zone.ru › Apache HTTP Server

Надёжное шифрование SSL/TLS: часто задаваемые вопросы

Мудрец не даёт правильных ответов, он задаёт правильные вопросы.

-- Клод Леви-Стросс

Установка

  • Почему при запуске Apache возникают ошибки разрешений, связанные с SSLMutex?
  • Почему при запуске Apache mod_ssl останавливается с ошибкой "Failed to generate temporary 512 bit RSA private key"?

Почему при запуске Apache возникают ошибки разрешений, связанные с SSLMutex?

Ошибки, такие как ``mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) [...] System: Permission denied (errno: 13)'', обычно возникают из-за чрезмерно ограниченных разрешений на родительские каталоги. Убедитесь, что для всех родительских каталогов (здесь /opt, /opt/apache и /opt/apache/logs) установлен бит x как минимум для UID, от имени которого работают дочерние процессы Apache (см. директиву User).

Почему при запуске Apache mod_ssl останавливается с ошибкой "Failed to generate temporary 512 bit RSA private key"?

Для правильной работы криптографическому программному обеспечению нужен источник непредсказуемых данных. Во многих операционных системах с открытым исходным кодом предусмотрено «устройство случайных чисел», выполняющее эту функцию (обычно оно называется /dev/random). В других системах приложения должны вручную инициализировать генератор псевдослучайных чисел OpenSSL (PRNG) подходящими данными перед созданием ключей или выполнением шифрования с открытым ключом. Начиная с версии 0.9.5, функции OpenSSL, которым нужны случайные данные, сообщают об ошибке, если в PRNG не было передано как минимум 128 бит случайных данных.

Чтобы предотвратить эту ошибку, mod_ssl должен предоставить PRNG достаточно энтропии для правильной работы. Это можно сделать с помощью директивы SSLRandomSeed.

Настройка

  • Можно ли предоставлять HTTP и HTTPS с одного сервера?
  • Какой порт использует HTTPS?
  • Как вручную отправить запрос HTTPS для тестирования?
  • Почему соединение зависает при подключении к серверу Apache с поддержкой SSL?
  • Почему при попытке обратиться по HTTPS к только что установленному серверу Apache+mod_ssl возникает ошибка ``Connection Refused''?
  • Почему переменные SSL_XXX недоступны моим скриптам CGI и SSI?
  • Как переключаться между HTTP и HTTPS в относительных гиперссылках?

Можно ли предоставлять HTTP и HTTPS с одного сервера?

Да. HTTP и HTTPS используют разные серверные порты (HTTP привязывается к порту 80, HTTPS — к порту 443), поэтому прямого конфликта между ними нет. Можно запустить два отдельных экземпляра сервера, привязанных к этим портам, либо воспользоваться удобной функцией виртуальных хостов Apache и создать два виртуальных сервера, обслуживаемых одним экземпляром Apache: один будет отвечать на запросы по HTTP через порт 80, а другой — по HTTPS через порт 443.

Какой порт использует HTTPS?

HTTPS можно запустить на любом порту, однако стандартами предусмотрен порт 443, который по умолчанию используют все браузеры, совместимые с HTTPS. Можно заставить браузер обращаться к другому порту, указав его в URL. Например, если сервер настроен на передачу страниц по HTTPS через порт 8080, обратиться к ним можно по адресу https://example.com:8080/

Как вручную отправить запрос HTTPS для тестирования?

Для простого тестирования Apache по HTTP обычно достаточно использовать

$ telnet localhost 80
GET / HTTP/1.0

но для HTTPS это не так просто из-за протокола SSL, расположенного между TCP и HTTP. Однако с помощью команды OpenSSL s_client можно выполнить аналогичную проверку через HTTPS:

$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0

Перед фактическим ответом HTTP вы получите подробную информацию о рукопожатии SSL. Если вам нужен универсальный клиент командной строки, который напрямую поддерживает HTTP и HTTPS, выполняет операции GET и POST, может использовать прокси-сервер, поддерживает диапазоны байтов и т. д., обратите внимание на удобную утилиту cURL. С её помощью можно проверить, правильно ли Apache отвечает на запросы по HTTP и HTTPS:

$ curl http://localhost/
$ curl https://localhost/

Почему соединение зависает при подключении к серверу Apache с поддержкой SSL?

Это может происходить, если вы пытаетесь подключиться к серверу HTTPS (или виртуальному серверу) по HTTP (например, используя http://example.com/ вместо https://example.com). Такое же может случиться при попытке подключиться по HTTPS к серверу HTTP (например, используя https://example.com/ на сервере, который не поддерживает HTTPS или поддерживает его на нестандартном порту). Убедитесь, что вы подключаетесь к серверу (виртуальному серверу), поддерживающему SSL.

Почему при попытке обратиться по HTTPS к только что установленному серверу Apache+mod_ssl возникает сообщение ``Connection Refused''?

Эта ошибка может быть вызвана неправильной настройкой. Убедитесь, что директивы Listen соответствуют директивам <VirtualHost>. Если ничего не помогает, начните настройку заново, используя конфигурацию по умолчанию, предоставленную mod_ssl.

Почему переменные SSL_XXX недоступны моим скриптам CGI и SSI?

Убедитесь, что для контекста запросов CGI/SSI включена директива «SSLOptions +StdEnvVars».

Как переключаться между HTTP и HTTPS в относительных гиперссылках?

Обычно для переключения между HTTP и HTTPS приходится использовать абсолютные гиперссылки (поскольку необходимо изменить схему URL). Однако с помощью mod_rewrite можно преобразовывать относительные гиперссылки и добиться того же результата.

RewriteEngine on
RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]

Этот набор правил перезаписи позволяет использовать гиперссылки вида <a href="document.html_SSL"> для переключения на HTTPS с помощью относительной ссылки. (Чтобы переключиться на HTTP, замените SSL на NOSSL.)

Сертификаты

  • Что такое закрытые ключи RSA, CSR и сертификаты?
  • Отличается ли запуск Apache с поддержкой SSL от запуска Apache без неё?
  • Как создать самоподписанный сертификат SSL для тестирования?
  • Как создать настоящий сертификат SSL?
  • Как создать и использовать собственный центр сертификации (CA)?
  • Как изменить парольную фразу файла закрытого ключа?
  • Как убрать запрос парольной фразы при запуске Apache?
  • Как проверить, соответствует ли закрытый ключ сертификату?
  • Как преобразовать сертификат из формата PEM в формат DER?
  • Почему браузеры сообщают, что не могут проверить сертификат сервера?

Что такое закрытые ключи RSA, CSR и сертификаты?

Файл закрытого ключа RSA — это цифровой файл, с помощью которого можно расшифровывать отправленные вам сообщения. Он содержит открытую часть, которую вы распространяете (в файле сертификата) и которая позволяет другим шифровать сообщения для вас.

Запрос на подпись сертификата (CSR) — это цифровой файл, содержащий ваш открытый ключ и ваше имя. Вы отправляете CSR в центр сертификации (CA), который подписывает его и преобразует в настоящий сертификат.

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

Общее описание протокола SSL см. в главе Введение.

Отличается ли запуск Apache с поддержкой SSL от запуска Apache без неё?

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

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

Как создать самоподписанный сертификат SSL для тестирования?

  1. Убедитесь, что OpenSSL установлен и находится в вашем PATH.

  2. Выполните следующую команду, чтобы создать файлы server.key и server.crt:
    $ openssl req -new -x509 -nodes -out server.crt -keyout server.key
    Их можно использовать в файле httpd.conf следующим образом:
    SSLCertificateFile    "/path/to/this/server.crt"
    SSLCertificateKeyFile "/path/to/this/server.key"
  3. Важно помнить, что у этого server.key нет парольной фразы. Чтобы добавить парольную фразу к ключу, выполните следующую команду и введите и подтвердите парольную фразу по запросу.

    $ openssl rsa -des3 -in server.key -out server.key.new
    $ mv server.key.new server.key

    Сохраните резервную копию файла server.key и введённую парольную фразу в надёжном месте.

Как создать настоящий сертификат SSL?

Ниже приведено пошаговое описание:

  1. Убедитесь, что OpenSSL установлен и находится в вашем PATH.

  2. Создайте закрытый ключ RSA для сервера Apache (он будет зашифрован с помощью Triple-DES и представлен в формате PEM):

    $ openssl genrsa -des3 -out server.key 2048

    Сохраните резервную копию этого файла server.key и введённую парольную фразу в надёжном месте. Подробную информацию об этом закрытом ключе RSA можно просмотреть с помощью команды:

    $ openssl rsa -noout -text -in server.key

    При необходимости можно также создать расшифрованную версию этого закрытого ключа RSA в формате PEM (не рекомендуется):

    $ openssl rsa -in server.key -out server.key.unsecure

  3. Создайте запрос на подпись сертификата (CSR) с помощью закрытого ключа RSA сервера (результат будет представлен в формате PEM):

    $ openssl req -new -key server.key -out server.csr

    Когда OpenSSL запросит «CommonName», укажите FQDN («полное доменное имя») сервера. Например, при создании CSR для веб-сайта, к которому впоследствии будут обращаться по адресу https://www.foo.dom/, укажите здесь «www.foo.dom». Подробную информацию об этом CSR можно просмотреть с помощью команды

    $ openssl req -noout -text -in server.csr

  4. Теперь необходимо отправить этот запрос на подпись сертификата (CSR) в центр сертификации (CA). После подписания CSR вы получите настоящий сертификат, который можно использовать в Apache. Можно отправить CSR на подпись коммерческому центру сертификации или создать собственный центр сертификации и подписать его самостоятельно.
    Коммерческие центры сертификации обычно предлагают вставить CSR в веб-форму, оплатить подпись, а затем отправляют подписанный сертификат, который можно сохранить в файле server.crt.
    Инструкции по созданию собственного центра сертификации и подписанию CSR см. ниже.
    После подписания CSR сведения о сертификате можно просмотреть следующим образом:

    $ openssl x509 -noout -text -in server.crt
  5. Теперь у вас должно быть два файла: server.key и server.crt. Их можно использовать в файле httpd.conf следующим образом:
    SSLCertificateFile    "/path/to/this/server.crt"
    SSLCertificateKeyFile "/path/to/this/server.key"
    Файл server.csr больше не нужен.

Как создать и использовать собственный центр сертификации (CA)?

Краткий ответ: используйте скрипт CA.sh или CA.pl, поставляемый вместе с OpenSSL. Если у вас нет веских причин поступить иначе, лучше использовать именно эти скрипты. Если это невозможно, можно создать самоподписанный сертификат следующим образом:

  1. Создайте закрытый ключ RSA для сервера (он будет зашифрован с помощью Triple-DES и представлен в формате PEM):

    $ openssl genrsa -des3 -out server.key 2048

    Сохраните резервную копию этого файла server.key и введённую парольную фразу в надёжном месте. Подробную информацию об этом закрытом ключе RSA можно просмотреть с помощью команды:

    $ openssl rsa -noout -text -in server.key

    При необходимости можно также создать расшифрованную версию этого закрытого ключа RSA в формате PEM (не рекомендуется):

    $ openssl rsa -in server.key -out server.key.unsecure

  2. Создайте самоподписанный сертификат (структура X509) с помощью созданного вами ключа RSA (результат будет представлен в формате PEM):

    $ openssl req -new -x509 -nodes -sha1 -days 365 -key server.key -out server.crt -extensions usr_cert

    Эта команда подписывает CSR сервера и создаёт файл server.crt.
    Подробную информацию об этом сертификате можно просмотреть с помощью команды:

    $ openssl x509 -noout -text -in server.crt

Как изменить парольную фразу файла закрытого ключа?

Достаточно прочитать файл, указав старую парольную фразу, а затем записать его заново, указав новую. Для этого выполните следующие команды:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

При первом запросе парольной фразы PEM введите старую парольную фразу. Затем появится повторный запрос парольной фразы — на этот раз введите новую. Если потребуется подтвердить парольную фразу, введите новую парольную фразу ещё раз.

Как убрать запрос парольной фразы при запуске Apache?

Это диалоговое окно появляется при запуске и каждом перезапуске, поскольку закрытый ключ RSA в файле server.key хранится в зашифрованном виде для обеспечения безопасности. Чтобы прочитать и обработать этот файл, его необходимо расшифровать с помощью парольной фразы. Удаление парольной фразы снижает уровень безопасности сервера — действуйте осторожно!

  1. Снимите шифрование с закрытого ключа RSA (сохранив резервную копию исходного файла):

    $ cp server.key server.key.org
    $ openssl rsa -in server.key.org -out server.key

  2. Убедитесь, что файл server.key доступен для чтения только пользователю root:

    $ chmod 400 server.key

Теперь server.key содержит незашифрованную копию ключа. Если указать этот файл для сервера, запрос парольной фразы появляться не будет. ОДНАКО, если кто-либо получит этот ключ, он сможет выдавать себя за вас в сети. ОБЯЗАТЕЛЬНО убедитесь, что разрешения на этот файл позволяют читать его только пользователю root или пользователю веб-сервера (желательно, чтобы веб-сервер запускался от root, а затем работал от имени другого пользователя, а ключ был доступен для чтения только root).

В качестве альтернативы можно использовать механизм «SSLPassPhraseDialog exec:/path/to/program». Конечно, он не является ни более, ни менее безопасным.

Как проверить, соответствует ли закрытый ключ сертификату?

Закрытый ключ содержит несколько чисел. Два из них образуют «открытый ключ», остальные являются частью «закрытого ключа». Биты «открытого ключа» включаются в CSR при его создании и впоследствии становятся частью соответствующего сертификата.

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

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

Части `modulus' и `public exponent' в ключе и сертификате должны совпадать. Поскольку открытый показатель обычно равен 65537, а визуально сравнить длинные числа модуля сложно, можно воспользоваться следующим способом:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

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

Если вы хотите проверить, к какому ключу или сертификату относится конкретный CSR, можно выполнить те же вычисления для CSR следующим образом:

$ openssl req -noout -modulus -in server.csr | openssl md5

Как преобразовать сертификат из формата PEM в формат DER?

Формат сертификатов OpenSSL по умолчанию — PEM. Он представляет собой данные DER, закодированные в Base64 и дополненные строками заголовка и окончания. Для некоторых приложений (например, Microsoft Internet Explorer) сертификат нужен в обычном формате DER. Преобразовать файл PEM cert.pem в соответствующий файл DER cert.der можно с помощью следующей команды: $ openssl x509 -in cert.pem -out cert.der -outform DER

Почему браузеры сообщают, что не могут проверить сертификат сервера?

Одна из возможных причин — сертификат сервера подписан промежуточным центром сертификации. Некоторые центры сертификации, например Verisign или Thawte, начали подписывать сертификаты не корневым, а промежуточным сертификатом.

Промежуточные сертификаты центров сертификации находятся между корневым сертификатом CA (установленным в браузерах) и сертификатом сервера (установленным на сервере). Чтобы браузер мог пройти по цепочке доверия от сертификата сервера до корневого сертификата и проверить её, ему необходимо передать промежуточные сертификаты. Центры сертификации должны предоставлять пакеты промежуточных сертификатов, которые можно установить на сервере.

Необходимо добавить эти промежуточные сертификаты с помощью директивы SSLCertificateChainFile.

Протокол SSL

  • Почему при высокой нагрузке на сервер возникает множество случайных ошибок протокола SSL?
  • Почему после начала обслуживания зашифрованного трафика SSL нагрузка на веб-сервер увеличилась?
  • Почему установление HTTPS-соединения с сервером иногда занимает до 30 секунд?
  • Какие шифры SSL поддерживает mod_ssl?
  • Почему при попытке использовать анонимные шифры Диффи — Хеллмана (ADH) возникает ошибка ``no shared cipher''?
  • Почему при подключении к только что установленному серверу возникает ошибка 'no shared ciphers'?
  • Почему нельзя использовать SSL с виртуальными хостами на основе имени/не на основе IP-адреса?
  • Можно ли использовать виртуальные хосты на основе имени для идентификации разных виртуальных хостов SSL?
  • Как включить сжатие SSL?
  • При использовании базовой аутентификации через HTTPS значок замка в браузерах Netscape остаётся открытым, когда появляется диалоговое окно. Означает ли это, что имя пользователя и пароль передаются незашифрованными?
  • Почему при подключении по HTTPS к серверу Apache+mod_ssl с помощью Microsoft Internet Explorer (MSIE) возникают ошибки ввода-вывода?
  • Как включить TLS-SRP?
  • Почему при использовании сертификата длиной более 1024 бит возникают ошибки рукопожатия с клиентами на Java?

Почему при высокой нагрузке на сервер возникает множество случайных ошибок протокола SSL?

Причин может быть несколько, но основная связана с проблемами кэша SSL-сеансов, заданного директивой SSLSessionCache. Вероятнее всего, проблема возникает из-за кэша сеансов DBM, поэтому может помочь использование кэша сеансов SHM (или полный отказ от кэширования).

Почему после начала обслуживания зашифрованного трафика SSL нагрузка на веб-сервер увеличилась?

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

Почему установление HTTPS-соединения с сервером иногда занимает до 30 секунд?

Обычно это вызвано устройством /dev/random для SSLRandomSeed, которое блокирует вызов read(2), пока не накопится достаточно энтропии для обработки запроса. Дополнительные сведения см. в справочном руководстве по директиве SSLRandomSeed.

Какие шифры SSL поддерживает mod_ssl?

Как правило, mod_ssl поддерживает все шифры SSL, доступные в используемой версии OpenSSL. Набор доступных шифров может зависеть от способа сборки OpenSSL. Обычно поддерживаются как минимум следующие шифры:

  1. RC4 с SHA1
  2. AES с SHA1
  3. Triple-DES с SHA1

Чтобы определить фактический список доступных шифров, выполните следующую команду:

$ openssl ciphers -v

Почему при попытке использовать анонимные шифры Диффи — Хеллмана (ADH) возникает ошибка ``no shared cipher''?

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

Чтобы использовать анонимные шифры Диффи — Хеллмана (ADH), необходимо собрать OpenSSL с параметром «-DSSL_ALLOW_ADH», а затем добавить «ADH» в SSLCipherSuite.

Почему при подключении к только что установленному серверу возникает ошибка 'no shared ciphers'?

Возможно, допущена ошибка в директиве SSLCipherSuite (сравните её с предварительно настроенным примером в extra/httpd-ssl.conf) или при создании закрытого ключа вы выбрали алгоритмы DSA/DH вместо RSA и проигнорировали или не заметили предупреждения. Если выбран DSA/DH, сервер не сможет обмениваться данными с помощью шифров SSL на основе RSA (по крайней мере, пока вы не настроите дополнительную пару сертификата и ключа на основе RSA). Современные браузеры, такие как NS или IE, могут обмениваться данными по SSL только с помощью шифров RSA. В результате возникает ошибка «no shared ciphers». Чтобы устранить её, заново создайте пару сертификата и ключа сервера, используя алгоритм RSA.

Почему нельзя использовать SSL с виртуальными хостами на основе имени/не на основе IP-адреса?

Причина связана с техническими особенностями и напоминает проблему «курицы и яйца». Уровень протокола SSL расположен ниже уровня протокола HTTP и инкапсулирует HTTP. При установлении SSL-соединения (HTTPS) Apache/mod_ssl должен согласовать параметры протокола SSL с клиентом. Для этого mod_ssl должен обратиться к конфигурации виртуального сервера (например, чтобы получить набор шифров, сертификат сервера и т. д.). Однако, чтобы выбрать правильный виртуальный сервер, Apache должен знать поле заголовка HTTP Host. Для этого необходимо прочитать заголовок HTTP-запроса. Это невозможно сделать до завершения рукопожатия SSL, но эта информация нужна для завершения рукопожатия. О том, как обойти эту проблему, см. следующий вопрос.

Обратите внимание: если у вас есть сертификат SSL с подстановочным знаком или сертификат с несколькими именами узлов в полях subjectAltName, SSL можно использовать с виртуальными хостами на основе имени без дополнительных обходных решений.

Можно ли использовать виртуальные хосты на основе имени для идентификации разных виртуальных хостов SSL?

Виртуальные хосты на основе имени — очень популярный способ идентификации различных виртуальных хостов. Он позволяет использовать один IP-адрес и один номер порта для множества разных сайтов. При переходе на SSL кажется естественным предположить, что таким же способом можно разместить на одном сервере множество виртуальных хостов SSL.

Это возможно, но только при использовании веб-сервера версии 2.2.12 или более поздней, собранного с OpenSSL версии 0.9.8j или более поздней. Это связано с необходимостью использовать функцию, добавленную только в самых последних редакциях спецификации SSL и называемую индикацией имени сервера (SNI).

Обратите внимание: если у вас есть сертификат SSL с подстановочным знаком или сертификат с несколькими именами узлов в полях subjectAltName, SSL можно использовать с виртуальными хостами на основе имени без дополнительных обходных решений.

Причина в том, что протокол SSL — это отдельный уровень, инкапсулирующий протокол HTTP. Поэтому сеанс SSL представляет собой отдельную транзакцию, происходящую до начала сеанса HTTP. Сервер получает запрос SSL на IP-адрес X и порт Y (обычно 443). Поскольку в запросе SSL нет поля Host:, сервер не может определить, какой виртуальный хост SSL использовать. Обычно он использует первый найденный виртуальный хост, соответствующий указанным порту и IP-адресу.

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

Разумеется, виртуальные хосты на основе имени можно использовать для идентификации множества виртуальных хостов без SSL (например, все они могут работать на порту 80), а затем настроить один виртуальный хост SSL (на порту 443). В этом случае необходимо указать номер порта без SSL в директиве NameVirtualHost, например:

NameVirtualHost 192.168.1.1:80

Другие способы обойти проблему:

Использовать отдельные IP-адреса для разных узлов SSL. Использовать разные номера портов для разных узлов SSL.

Как включить сжатие SSL?

Хотя согласование сжатия SSL было определено в спецификациях SSLv2 и TLS, стандартный метод сжатия DEFLATE был определён для согласования только в мае 2004 года, с публикацией RFC 3749.

OpenSSL 0.9.8 начала поддерживать эту функцию по умолчанию при сборке с параметром zlib. Если сжатие поддерживают и клиент, и сервер, оно будет использоваться. Однако большинство клиентов по-прежнему пытаются начать соединение с помощью приветствия SSLv2. Поскольку в SSLv2 при рукопожатии не передаётся список предпочтительных алгоритмов сжатия, согласовать сжатие с такими клиентами невозможно. Если клиент отключит поддержку SSLv2, может быть отправлено приветствие SSLv3 или TLS — в зависимости от используемой библиотеки SSL, — и сжатие может быть настроено. Проверить, используют ли клиенты сжатие SSL, можно, записывая переменную %{SSL_COMPRESS_METHOD}x.

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

Нет, имя пользователя и пароль передаются в зашифрованном виде. Значок в браузерах Netscape на самом деле не синхронизирован с уровнем SSL/TLS. Он переходит в закрытое состояние только после передачи первой части данных веб-страницы, что может сбивать пользователей с толку. Механизм базовой аутентификации относится к уровню HTTP, расположенному в HTTPS выше уровня SSL/TLS. До начала обмена данными HTTP через HTTPS уровень SSL/TLS уже завершает этап рукопожатия и переключается на зашифрованный обмен данными. Поэтому не обращайте внимания на этот значок.

Почему при подключении по HTTPS к серверу Apache+mod_ssl с помощью старых версий Microsoft Internet Explorer (MSIE) возникают ошибки ввода-вывода?

Первая причина заключается в том, что в реализации SSL некоторых версий MSIE есть малозаметные ошибки, связанные с поддержкой постоянных HTTP-соединений и уведомлениями SSL о закрытии при закрытии сокетного соединения. Кроме того, в некоторых версиях MSIE возникают проблемы при совместном использовании SSL и функций HTTP/1.1. Чтобы обойти эти проблемы, можно запретить Apache использовать HTTP/1.1, постоянные соединения или отправлять клиентам MSIE уведомления SSL о закрытии. Для этого используйте следующую директиву в разделе виртуального хоста с поддержкой SSL:

SetEnvIf User-Agent "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

Кроме того, в некоторых версиях MSIE возникают проблемы с определёнными шифрами. К сожалению, реализовать обходное решение специально для MSIE невозможно, поскольку шифры используются уже на этапе рукопожатия SSL. Поэтому директива SetEnvIf для MSIE не поможет устранить эти проблемы. Вместо этого придётся внести более серьёзные изменения в глобальные параметры. Прежде чем делать это, убедитесь, что у клиентов действительно возникают проблемы. Если нет, не вносите эти изменения — они повлияют на всех ваших клиентов, а не только на MSIE.

Как включить TLS-SRP?

TLS-SRP (обмен ключами по протоколу Secure Remote Password для TLS, определённый в RFC 5054) может дополнять сертификаты или заменять их при аутентификации SSL-соединения. Чтобы использовать TLS-SRP, настройте директиву SSLSRPVerifierFile так, чтобы она указывала на файл проверочных данных SRP OpenSSL. Для создания этого файла используйте утилиту openssl:

openssl srp -srpvfile passwd.srpv -add username

После создания файла укажите его в конфигурации сервера SSL:

SSLSRPVerifierFile /path/to/passwd.srpv

Чтобы заставить клиентов использовать наборы шифров TLS-SRP без сертификатов, примените следующую директиву:

SSLCipherSuite "!DSS:!aRSA:SRP"

Почему при использовании сертификата длиной более 1024 бит возникают ошибки рукопожатия с клиентами на Java?

Начиная с версии 2.4.7, mod_ssl использует параметры DH с простыми числами длиной более 1024 бит. Однако Java 7 и более ранние версии поддерживают простые числа DH длиной не более 1024 бит.

Если клиент на Java прерывает работу с исключениями, такими как java.lang.RuntimeException: Could not generate DH keypair и java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive), а в журнале httpd появляется запись tlsv1 alert internal error (SSL alert number 80) (на уровне LogLevel info или выше), можно изменить порядок списка шифров mod_ssl с помощью SSLCipherSuite (возможно, совместно с SSLHonorCipherOrder) либо использовать собственные параметры DH с простым числом длиной 1024 бита. Такие параметры всегда имеют приоритет над встроенными параметрами DH.

Чтобы создать собственные параметры DH, используйте команду openssl dhparam 1024. Также можно воспользоваться следующими стандартными параметрами DH длиной 1024 бита из раздела 6.2 документа RFC 2409:

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

Добавьте собственные параметры, включая строки «BEGIN DH PARAMETERS» и «END DH PARAMETERS», в конец первого файла сертификата, настроенного с помощью директивы SSLCertificateFile.

Поддержка mod_ssl

  • Какие информационные ресурсы доступны при возникновении проблем с mod_ssl?
  • Куда можно обратиться за помощью при возникновении проблем с mod_ssl?
  • Какую информацию следует указать в отчёте об ошибке?
  • Произошёл аварийный сброс памяти — можете помочь?
  • Как получить трассировку стека, чтобы выяснить причину аварийного сброса памяти?

Какие информационные ресурсы доступны при возникновении проблем с mod_ssl?

Доступны следующие информационные ресурсы. В случае возникновения проблем сначала поищите информацию здесь.

Ответы в списке часто задаваемых вопросов руководства пользователя (этот документ)
http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html
Сначала проверьте список часто задаваемых вопросов (этот текст). Если ваша проблема распространённая, на неё, возможно, уже неоднократно отвечали, и ответ был включён в этот документ.

Куда можно обратиться за поддержкой при возникновении проблем с mod_ssl?

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

  1. Отправьте сообщение о проблеме в список рассылки поддержки пользователей Apache httpd
    users@httpd.apache.org
    Это второй способ отправить сообщение о проблеме. Сначала необходимо подписаться на список рассылки, после чего вы сможете без труда обсудить проблему со всем сообществом пользователей Apache httpd.
  2. Создайте сообщение о проблеме в базе данных ошибок
    http://httpd.apache.org/bug_report.html
    Это последний способ отправить сообщение о проблеме. Пользуйтесь им, только если вы уже обращались в списки рассылки, но безуспешно. Пожалуйста, внимательно следуйте инструкциям на указанной выше странице.

Какую информацию следует указать в сообщении об ошибке?

Всегда указывайте как минимум следующие сведения:

Сведения о версиях Apache httpd и OpenSSL
Версию Apache можно определить, выполнив httpd -v. Версию OpenSSL можно определить, выполнив openssl version. Кроме того, если у вас установлен Lynx, можно выполнить команду lynx -mime_header http://localhost/ | grep Server, чтобы получить эти сведения за один шаг.
Сведения о сборке и установке Apache httpd и OpenSSL
Для этого можно приложить файл журнала сеанса работы в терминале, в котором показаны этапы настройки и установки. Если это невозможно, укажите хотя бы командную строку configure, которую вы использовали.
При аварийном завершении с созданием дампа памяти приложите трассировку стека
Если Apache httpd создал дамп памяти, приложите трассировку стека (см. ниже, где описано, как её получить). Эта информация необходима для выяснения причины создания дампа памяти.
Подробное описание проблемы
Не смейтесь — мы действительно серьёзно! Во многих сообщениях об ошибках не описывается, в чём именно заключается проблема. Без этого другим будет очень трудно вам помочь. Поэтому в ваших же интересах (вы ведь хотите решить проблему, не так ли?) предоставить как можно больше подробностей. Разумеется, не забудьте также указать все перечисленные выше основные сведения.

Произошёл сбой с созданием дампа памяти. Вы можете помочь?

Как правило, нет — по крайней мере, если вы не предоставите дополнительные сведения о месте в коде, где произошёл сбой Apache. Для оказания помощи обычно всегда требуется трассировка стека (см. следующий вопрос). Без этой информации чаще всего невозможно определить проблему и помочь вам её устранить.

Как получить трассировку стека, чтобы выяснить причину создания дампа памяти?

Чтобы получить трассировку стека, выполните следующие действия:

  1. Убедитесь, что у вас доступны отладочные символы, по крайней мере для Apache. На платформах, где используются GCC/GDB, для этого необходимо собрать Apache+mod_ssl с параметром ``OPTIM="-g -ggdb3"''. На других платформах требуется как минимум ``OPTIM="-g"''.
  2. Запустите сервер и попытайтесь воспроизвести сбой с созданием дампа памяти. Для этого можно использовать такую директиву, как ``CoreDumpDirectory /tmp'', чтобы убедиться, что файл дампа памяти может быть записан. В результате должен появиться файл /tmp/core или /tmp/httpd.core. Если ни один из этих файлов не появился, попробуйте запустить сервер с UID, отличным от root. Многие современные ядра не позволяют процессу создавать дамп памяти после выполнения setuid() (если только он не выполняет exec()) по соображениям безопасности (в памяти могут оставаться привилегированные данные). При необходимости можно вручную запустить /path/to/httpd -X, чтобы запретить Apache создавать дочерние процессы.
  3. Проанализируйте дамп памяти. Для этого выполните gdb /path/to/httpd /tmp/httpd.core или аналогичную команду. В GDB достаточно ввести bt — и вы получите трассировку стека. Инструкции для других отладчиков см. в руководстве к соответствующему отладчику.

© 2018 The Apache Software Foundation
Licensed under the Apache License, Version 2.0.
https://httpd.apache.org/docs/2.4/en/ssl/ssl_faq.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API