Вопрос: Настройка аутентификации сертификата клиента в apache


Я пытаюсь создать часть Virtualhost в apache требуется аутентификация клиента. VirtualHost в вопросе также выступает в качестве обратного прокси-сервера для фактического веб-сервера. Вот что я сделал:

  • созданный ca.crt, ca.csr, а также ca.key на сервере, который я использую как CA.
  • Изменена конфигурация VirtualHost чтобы выглядеть так:

...

ProxyPass / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverseCookiePath / /

SSLEngine On
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
SSLCertificateChainFile "/private/etc/apache2/ca_bundle.crt"
SSLCACertificateFile "/private/etc/apache2/self_ca.crt"
SSLVerifyClient none
SSLOptions StrictRequire   
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /clientauth>
    # These options force the client to authenticate with a client certificate.
    SSLVerifyClient require
    SSLVerifyDepth 1
</Location>
  • Создал тестовый клиентский сертификат, используя мой собственный CA.
  • Установил сертификат клиента в брелок для входа в Mac OS X Lion и вручную в Firefox.

Но я не могу /clientauth дорожка.

  • Firefox говорит: «SSL-партнер не смог согласовать приемлемый набор параметров безопасности».
  • Opera говорит: «Безопасное соединение: фатальная ошибка (40) с сервера».
  • Chrome и Safari говорят «HTTP 403 Forbidden».
  • cURL (с использованием файла .p12) по какой-то причине не может найти ключ ...
  • cURL (с использованием файлов .crt и .key) выполняет рукопожатие, отправляет запрос и затем говорит «Empty reply from server».
  • Журналы ошибок apache повторяют строку Re-negotiation handshake failed: Not accepted by client!?

Является ли это конфликтом между использованием аутентификации клиента и обратным прокси-сервером? Или я сделал что-то еще неправильно?


7
2017-07-25 04:08


Источник




Ответы:


Основная проблема здесь - отказ от пересмотра. Это связано с активностью в течение последнего года или двух, чтобы устранить уязвимость TLS, и существовали различные промежуточные исправления отказа от пересмотра до тех пор, пока не было реализовано новое расширение TLS. Итак, вам нужно сделать все, чтобы обеспечить ваш SSL (OpenSSL) и, возможно, ваш Apache HTTPD также является как можно более актуальным.


5
2017-07-26 07:15



Оказывается, сервер имел OpenSSL 0.9.8l, версию, в которой они полностью отключили пересмотр. Обновление должно исправить это, спасибо. - DanielGibbs
@DanielGibbs, обновил OpenSSL исправить свою проблему? Какую версию вы обновили? - Kevin Meredith
Привет, Кевин, я решил исправить эту проблему, обновив оба Apache и OpenSSL до (я думаю) последних версий, когда был задан этот вопрос. Я посмотрю, когда приеду на работу, и я вернусь к тебе. - DanielGibbs
Apache - версия 2.4.2, а OpenSSL - 0.9.8r (февраль 2011 года, а не недавнее после). - DanielGibbs


HTTP-клиент отправляет HTTP-запрос только после согласования сеанса SSL, а это значит, что сервер только знает URL-адрес, запрошенный клиентом после установки SSL. Поскольку вы меняете значение SSLVerifyClient основанный на URL-адресе, Apache не может запрашивать сертификат клиента, когда сеанс SSL сначала согласовывается, и вместо этого требуется принудительное повторное рассмотрение сеанса после того, как он узнает URL. Кажется, что проблема заключается в этом пересмотре, поэтому я предлагаю вам протестировать ее без этого, установив SSLVerifyClient require в VirtualHost блокировать и удалять его из Location блок.


5
2017-07-25 05:55



Ах, это имеет смысл. Тогда как мне настроить его так, чтобы только путь на самом деле требовал, чтобы клиент имел действительный сертификат? - DanielGibbs
@DanielGibbs То, как вы это сделали, совершенно правильно, но оно зависит от того, что клиент согласен с пересмотренным соглашением: см. Мой ответ. - user207421
Я столкнулся с той же проблемой, что и в вопросе, и я попытался реализовать ваше решение. Я поставил Директивы SSLVerifyClient require а также SSLVerifyDepth 1 в VirtualHost Блок. Теперь я могу открыть SSL-соединение, но сертификат клиента не распознается, и Location фактически незащищен. Любой может его открыть. - Bodo Hugo Barwich