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

Ошибки аутентификации сертификата клиента apache: Проверка сертификата: Ошибка (18): самоподписанный сертификат

Итак, я следовал инструкциям по настройке аутентификации сертификата клиента в Apache2 с mod_ssl. Это сделано исключительно с целью тестирования приложения на соответствие CAA, а не для любого производственного использования.

Пока я следил http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html за советом по созданию моей информации о шифровании CA, сервера и клиента. Я поместил всех троих в /etc/ssl/ca/private. Я установил следующие дополнительные директивы в моем файле сайта default_ssl:

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
...
    SSLEngine on
    SSLCertificateFile    /etc/ssl/ca/private/server.crt
    SSLCertificateKeyFile /etc/ssl/ca/private/server.key
    SSLVerifyClient require
    SSLVerifyDepth 2

    SSLCACertificatePath /etc/ssl/ca/private
    SSLCACertificateFile /etc/ssl/ca/private/ca.crt
    <Location />
            SSLRequireSSL
            SSLVerifyClient require
            SSLVerifyDepth 2
    </Location>
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>
...
</VirtualHost>
</IfModule>

Я установил файл p12 в Chrome, но когда я иду в гости https: // localhost, Я получаю следующие ошибки

Хром: Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Apache: Certificate Verification: Error (18): self signed certificate

Если бы мне пришлось угадывать, одна из моих директив не настроена правильно для загрузки и проверки p12 с моим самим созданным ЦС. Но я не могу понять, что это такое. Есть ли у кого-нибудь здесь больше опыта, который мог бы указать мне правильное направление?

Во-первых, я бы посоветовал избегать использования обоих SSLCACertificatePath и SSLCACertificateFile в то же время. SSLCACertificatePath используется для указания каталога, содержащего несколько файлов, по одному для каждого сертификата ЦС, которому вы доверяете. SSLCACertificateFile используется для указания на один файл, являясь объединением всех сертификатов CA, которым вы доверяете. На самом деле нет смысла указывать SSLCACertificatePath в каталог, который также содержит закрытые ключи (хотя я не уверен, что это все равно вызовет проблемы).

Важно то, что используемый вами сертификат клиента выдается одним из сертификатов ЦС (на который указывает любой из SSLCACertificatePath или SSLCACertificateFile вы будете использовать): DN издателя вашего клиентского сертификата должен быть DN субъекта одного из сертификатов CA, которые вы настроили таким образом в Apache Httpd (кроме того, он действительно должен быть выпущен этим CA, поэтому ваш клиент подпись сертификата должна быть проверена открытым ключом сертификата CA, но я предполагаю, что вы создали свой CA и правильно выпустили сертификаты: вы можете проверить это, на всякий случай).

Вы можете проверить содержимое сертификата (CA или нет) в форме PEM (часто .pem или .crt) с помощью:

openssl x509 -text -noout -in filename.pem

(Это должно отобразить достаточно информации о сертификате.)

РЕДАКТИРОВАТЬ:

На всякий случай, если возникла проблема с вашими сертификатами, вы можете попробовать эти тестовые сертификаты:

http://jsslutils.googlecode.com/svn/tags/jsslutils-root-1.0.7/certificates/src/main/resources/org/jsslutils/certificates/local/

(Все пароли testtest.)

Вы можете импортировать testclient.p12 в ваш браузер. cacert.pem это сертификат CA в формате PEM, и localhost-cert.pem это сертификат сервера для localhost (так что он предназначен для тестирования с самой машины). localhost-key.pem - закрытый ключ для сертификата сервера. Вы можете снять защиту, используя:

openssl rsa -in localhost-key.pem -out localhost-key-unprotected.pem

Вам может понадобиться доверять cacert.pem временно в вашем браузере, но удалите его после тестов (потому что, очевидно, testtest не является секретом, поэтому любой может использовать этот CA).

У меня была такая же проблема (под Nginx). Решение заключалось в том, чтобы сделать общее имя моего клиента отличным от общего имени сертификатов сервера. Первоначально я думал, что мой сертификат CN должен соответствовать FQDN сертификата сервера.

EX:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Minnesota
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCo
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Ryan Pendergast
Email Address []:me@gmail.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Signature ok
subject=/C=US/ST=Minnesota/O=MyCo/CN=Ryan Pendergast/emailAddress=me@gmail.com

У меня тоже была эта проблема с nginx, как и в случае с @rynop, решение оказалось правильным с именами.

В моем случае это было решено, если организация / общие имена для клиентского центра сертификации и клиентского сертификата были разными.

Если имена совпадают, nginx / openssl видит самозаверяющий сертификат вместо сертификата, подписанного центром сертификации.

Следующее руководство было полезно при настройке аутентификации сертификата клиента с помощью nginx и помогает использовать разные имена для CA и cert:

https://gist.github.com/mtigas/952344#convert-client-key-to-combined-pem