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

Проверка подлинности пользователя SSL не работает в Apache

У меня проблема с аутентификацией клиентов через их ssl-сертификаты, что похоже на множество проблем, которые я обнаружил в сети - к сожалению, без решения.

Установка: apache 2.2, mod_ssl, openssl в Debian linux. У меня есть клиент, использующий сертификат Globalsign PersonalSign для аутентификации. У меня есть настройка SSLCACertificatePath, я думаю правильно, поскольку отладка apache сообщает мне:

[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2
[Thu May 10 15:31:35 2012] [debug] ssl_engine_init.c(1196): CA certificate: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

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

Теперь клиент проходит аутентификацию (я копирую то, что я считаю релевантными записями из журнала отладки):

Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Certificate Verification: Error (20): unable to get local issuer certificate
OpenSSL: Write: SSLv3 read client certificate B
OpenSSL: Exit: error in SSLv3 read client certificate B
Re-negotiation handshake failed: Not accepted by client!?

что, насколько я понимаю, означает, что он не может получить сертификат эмитента для промежуточного GlobalSign PersonalSign 1 CA - G2 сертификат. Фактически Issuer_hash этого сертификата совпадает с хешем Корневой центр сертификации GlobalSign который действительно находится в SSLCACertificatePath, правильно связанном с этим самым хешем и упомянутым ранее в журнале как загруженный.

Так что я застрял. Есть идеи?

Редактировать:

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

# openssl verify -CApath conf/ssl.user.crt/ test.pem  
test.pem: OK

(conf / ssl.user.crt это мой SSLCACertificatePath)

Решил это. Оказывается, это проблема с разрешениями:

Я установил аналогичные настройки на чистой машине Debian Squeeze, и она сработала с самого начала. Разница в выводе отладки была:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 2, subject: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA 
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 0, subject: /CN=kettensaege@massaker.de/emailAddress=kettensaege@massaker.de, issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2

с "хорошей" стороны, по сравнению с:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[error] [client 80.252.98.156] Certificate Verification: Error (20): unable to get local issuer certificate

на «плохой» стороне.

Основное различие между этими двумя настройками - это разрешения для каталога / conf установки apache, в которой находятся CA-сертификаты. По соображениям безопасности у нас установлены права доступа 750 и каталог, принадлежащий пользователю root. Перемещение файлов CA в каталог, доступный для чтения (или, если быть точным, в «исполняемый файл», который будет использоваться в пути), устраняет проблему.

Таким образом, кажется, что хотя mod_ssl утверждает, что читает сертификаты при запуске сервера, ему все еще нужен доступ к хешированным файлам во время работы (и после отказа от корневых привилегий).