Назад | Перейти на главную страницу

Настройка https с помощью самозаверяющего сертификата на Apache

Я пытаюсь настроить HTTPS на Apache, используя самозаверяющий сертификат. Но вместо отображения страницы я получаю кучу странных ошибок. В каждом браузере своя ошибка!

Из Chrome:

Ошибка 2 (net :: ERR_FAILED): неизвестная ошибка.

Из Firefox:

SSL получил запись, длина которой превышает максимально допустимую. (Код ошибки: ssl_error_rx_record_too_long)

Я выполнил шаги, описанные на http://slacksite.com/apache/certificate.php, а также около 4 других гайдов. Все они примерно одинаковы, но все дают одинаковый результат. Так что я, должно быть, делаю что-то не так.

Вкратце вот что я сделал:

[при создании запроса я осторожно ввел свое фактическое имя хоста как «Общее имя (например, ваше имя или имя хоста вашего сервера)»]

Любые идеи?

ОБНОВИТЬ: Вот моя конфигурация виртуального хоста:

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)

Чтобы обобщить:

  1. В 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 ]
  2. Откройте командную строку вверх, перейдите к apache \ bin и выполните следующую команду:

    openssl req -config openssl.conf -new -out server.csr

  3. При появлении запроса введите парольную фразу, а затем второй раз для подтверждения.

  4. Затем вам будет предложено ввести общее имя [Имя моего сервера]. Введите название машины

  5. Затем удалите кодовую фразу из закрытого ключа с помощью следующей команды (обратите внимание, что это может дать предупреждение о невозможности найти openssl.conf - это можно игнорировать):

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

  6. При появлении запроса введите ранее использованную парольную фразу.

  7. Затем создайте самоподписанный сертификат с помощью следующей команды

    `openssl x509 -in server.csr -out server.cert -req -signkey server.key -days 365

  8. Удалите файл server.csr из папки apache \ bin.

  9. Скопируйте файлы server.key и server.cert из папки apache \ bin в папку apache \ conf.

  10. Откройте apache \ conf \ httpd.conf в текстовом редакторе.

  11. Измените директиву порта прослушивания (которая, вероятно, будет Listen 80 или Listen 8080) на порт 443:

    Listen 443

  12. Измените директиву ServerName, чтобы включить порт 443 (обратите внимание, что это может быть закомментировано, поэтому удалите # в начале строки, если это так, и замените server на имя вашего сервера):

    ServerName server:443

  13. Раскомментируйте или добавьте директиву модуля загрузки для mod_ssl (она должна присутствовать и прокомментирована, поэтому удалите # в начале строки):

    LoadModule ssl_module modules/mod_ssl.so

  14. Добавьте раздел 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>
  15. Перезапустите службу 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 Я не знаю, почему это сработало. Я просто взял эту конфигурацию в качестве примера с реального живого сервера и повторно использовал ее в своей настройке, и она сработала.