Я пытаюсь настроить HTTPS на Apache, используя самозаверяющий сертификат. Но вместо отображения страницы я получаю кучу странных ошибок. В каждом браузере своя ошибка!
Из Chrome:
Ошибка 2 (net :: ERR_FAILED): неизвестная ошибка.
Из Firefox:
SSL получил запись, длина которой превышает максимально допустимую. (Код ошибки: ssl_error_rx_record_too_long)
Я выполнил шаги, описанные на http://slacksite.com/apache/certificate.php, а также около 4 других гайдов. Все они примерно одинаковы, но все дают одинаковый результат. Так что я, должно быть, делаю что-то не так.
Вкратце вот что я сделал:
Сгенерируйте ключ сервера:
openssl genrsa -des3 -out server.key 1024
Создать CSR:
openssl req -new -key server.key -out server.csr
[при создании запроса я осторожно ввел свое фактическое имя хоста как «Общее имя (например, ваше имя или имя хоста вашего сервера)»]
удалить пароль из ключа:
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
Самостоятельно подписать сертификат:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Настроил apache, чтобы он указывал на эти файлы и использовал эти сертификаты.
Любые идеи?
ОБНОВИТЬ: Вот моя конфигурация виртуального хоста:
LoadModule ssl_module modules/mod_ssl.so
Listen 443
# Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
## Virtual host to redirect to HTTPS
<VirtualHost *:80>
ServerName mail.craimer.org
Redirect permanent / https://mail.craimer.org:443
</VirtualHost>
##
## SSL Virtual Host Context
##
<VirtualHost mail.craimer.org:443>
ServerName mail.craimer.org
DocumentRoot "/usr/share/roundcubemail/trunk/roundcubemail/"
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/httpd/conf/ssl/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# Deal with broken MSIE
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
Проблема, скорее всего, связана с вашей конфигурацией виртуального хоста.
В ssl_error_rx_record_too_long
ошибка может быть вызвана инициированием сеанса HTTPS для ресурса HTTP. Такие как - https://host.name:80
.
Подход, который я использовал в прошлом, немного отличается от описанного вами. Приведенные ниже инструкции были изначально подробно описаны в этом посте, который я обнаружил, когда искал, как настроить ssl: Пошаговая установка Subversion поверх Apache / SSL с аутентификацией через Active Directory (SSPI)
Чтобы обобщить:
В apache \ bin создайте openssl.conf и установите его содержимое следующим образом:
[ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true [ req ] default_bits = 1024 default_keyfile = server.key distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = nombstr [ req_distinguished_name ] commonName = Common Name commonName_default = My Server Name [ req_attributes ]
Откройте командную строку вверх, перейдите к apache \ bin и выполните следующую команду:
openssl req -config openssl.conf -new -out server.csr
При появлении запроса введите парольную фразу, а затем второй раз для подтверждения.
Затем вам будет предложено ввести общее имя [Имя моего сервера]. Введите название машины
Затем удалите кодовую фразу из закрытого ключа с помощью следующей команды (обратите внимание, что это может дать предупреждение о невозможности найти openssl.conf - это можно игнорировать):
openssl rsa -in server.key -out server.key
При появлении запроса введите ранее использованную парольную фразу.
Затем создайте самоподписанный сертификат с помощью следующей команды
`openssl x509 -in server.csr -out server.cert -req -signkey server.key -days 365
Удалите файл server.csr из папки apache \ bin.
Скопируйте файлы server.key и server.cert из папки apache \ bin в папку apache \ conf.
Откройте apache \ conf \ httpd.conf в текстовом редакторе.
Измените директиву порта прослушивания (которая, вероятно, будет Listen 80 или Listen 8080) на порт 443:
Listen 443
Измените директиву ServerName, чтобы включить порт 443 (обратите внимание, что это может быть закомментировано, поэтому удалите # в начале строки, если это так, и замените server на имя вашего сервера):
ServerName server:443
Раскомментируйте или добавьте директиву модуля загрузки для mod_ssl (она должна присутствовать и прокомментирована, поэтому удалите # в начале строки):
LoadModule ssl_module modules/mod_ssl.so
Добавьте раздел IfModule для mod_ssl (его там еще не должно быть, но если он будет перезаписан):
<IfModule mod_ssl.c> SSLEngine on SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLPassPhraseDialog builtin SSLSessionCache dbm:logs/ssl_scache SSLSessionCacheTimeout 300 SSLMutex default SSLCertificateFile conf\server.cert SSLCertificateKeyFile conf\server.key </IfModule>
Перезапустите службу Apache. Протестируйте конфигурацию, попытавшись (и потерпев неудачу) подключиться через http, и попытавшись (и успешно) подключиться через https.
Что ж, поскольку пользователь Jure1873 не написал ответа, я не могу отдать ему должное. Вот его решение:
что если вы замените
<VirtualHost mail.craimer.org:443>
с участием<virtualhost *:443>
?
И это было решением. Оказывается, (на момент написания этой статьи) httpd
не может поддерживать несколько виртуальных хостов для HTTPS, поэтому любые подключения к 443 должны быть направлены на один хост. Так что я думаю httpd
просто молча отклонял конфигурацию, которая пыталась запустить виртуальный хост для HTTPS.
О, и не ругайте apache за эту «недостающую функцию». Это не их вина! Протокол HTTPS не поддерживает виртуальные хосты.
Видите ли, когда вы подключаетесь к порту 443 и запускаете сеанс HTTPS, все, что происходит, - это согласование безопасности. HTTPS предназначен для создания безопасного туннеля между двумя точками и не имеет ничего общего с HTTP. Только после того, как туннель настроен, данные будут проходить через него. Эти данные - поток HTTP.
Это означает, что Host:
Директива (которая является частью HTTP, а не HTTPS) будет отправлена только после создания безопасного туннеля. Это Host:
заголовок, который сообщает HTTP-серверу, к какому виртуальному хосту осуществляется доступ. Но в HTTPS мы получаем эту информацию слишком поздно: она приходит после того, как нам нужно было выбрать ключи шифрования.
Нижняя граница: HTTPS не может выбрать ключи шифрования на основе HTTP имя хоста.
Удалите тег из конфигурации VirtualHost. НАПРИМЕР. <IfModule mod_ssl.c >
</IfModule>
- удалить эти строки
Вот еще одна ситуация, в которой возникает эта ошибка:
Определить VirtualHost *:80
в sites-enabled/000-default.conf
. Затем определите VirtualHost *:443
в httpd.conf
Если вы полностью переместите конфигурацию в httpd.conf
или чтобы 000-default.conf
оно работает. В противном случае вы получите эту ошибку в FireFox:
SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)
и эта ошибка на хроме:
This site can’t provide a secure connection
... sent an invalid response.
Скраймер, принятый ответ неверен, иначе как вы думаете, почему директива SSLCertificateFile может находиться в области виртуального хоста? Доказательство: http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile
С виртуальными хостами вы по-прежнему можете использовать разные файлы сертификатов с виртуальными хостами на основе имени.
У меня была такая же проблема, и решение заключалось в том, чтобы указать реальный IP вместо * в директиве VirtualHost, например:
NameVirtualHost *:80
NameVirtualHost *:443
<VirtualHost 127.0.0.1:443>
ServerName affx.meg
...
</VirtualHost>
P.S. Hovewer Я не знаю, почему это сработало. Я просто взял эту конфигурацию в качестве примера с реального живого сервера и повторно использовал ее в своей настройке, и она сработала.