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

Как заставить Apache доверять сертификату клиента с использованием неизвестного ЦС без проверки ЦС

Я в следующей ситуации. Мне нужно настроить двустороннюю интеграцию с внешней системой. Администратор внешней системы потребовал, чтобы я отправил два CSR, один для генерации сертификата клиента, другой для генерации сертификата сервера. Прислали мне соответствующие справки. Я успешно настроил канал me-> they (то есть: я могу вызвать их службу, предоставляющую мой сертификат клиента), но я не могу правильно настроить обратный канал (то есть: я не могу заставить свой Apache принимать их сертификат клиента без жалоб).

Вместе с моим сертификатом сервера (назовем его my-server.pem) они также прислали мне свой собственный сертификат клиента (назовем его их-client.pem). Этот сертификат (их-client.pem) выдается «самоподписанным» ЦС, то есть ЦС, не входящим в число известных ЦС, уже доступных в моей системе Linux. У меня нет этого сертификата, и я еще не смог получить его от внешних системных администраторов (они не хотят ... давайте отложим любые комментарии по этому поводу, пожалуйста ...> - |)

Вот как я настроил свой VirtualHost в Apache:

SSLEngine on
SSLCertificateFile /path/to/my-server.pem
SSLCertificateKeyFile /path/to/my-server-secret-key.key
SSLVerifyClient require
SSLCACertificateFile /path/to/their-client.pem
SSLVerifyDepth 0

Поскольку у меня нет сертификата ЦС, и поскольку я могу сказать «просто доверяйте этому сертификату клиента, никому другому!», Я поставил сам сертификат клиента как SSLCACertificateFile, как предложено в ответе на: https://security.stackexchange.com/questions/36069/use-client-certificate-using-self-signed-ca- while-using-web-certificate-of-a-pub

Однако, похоже, это не работает. Ошибка, которую они видят на своей стороне:

javax.net.ssl.SSLException: Received fatal alert: unknown_ca

После включения журнала SSL и настройки его на отладку я вижу на своей стороне:

[ssl:debug] [pid 3396] ssl_engine_kernel.c(1381): [client <their-ip>:41474] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: CN=Test CA,OU=Foo,O=Bar,C=it / issuer: CN=Test CA,OU=Foo,O=Bar,C=it / serial: 1BFE / notbefore: Dec  6 15:22:45 2010 GMT / notafter: Dec  6 15:21:52 2020 GMT]
[ssl:info] [pid 3396] [client <their-IP>:41474] AH02276: Certificate Verification: Error (19): self signed certificate in certificate chain [subject: CN=Test CA,OU=Foo,O=Bar,C=it / issuer: CN=Test CA,OU=Foo,O=Bar,C=it / serial: 1BFE / notbefore: Dec  6 15:22:45 2010 GMT / notafter: Dec  6 15:21:52 2020 GMT]
[ssl:info] [pid 3396] [client <their-IP>:41474] AH02008: SSL library error 1 in handshake (server my-server.com:443)
[ssl:info] [pid 3396] SSL Library Error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
[ssl:info] [pid 3396] [client <their-IP>:41474] AH01998: Connection closed to child 54 with abortive shutdown (server my-server.com:443)

Другими словами, он все еще пытается проверить фиктивный ЦС сертификата клиента. Я тоже пытался изменить SSLVerifyDepth до 1, безуспешно (та же ошибка). Если я отключу запрос сертификата клиента (изменив SSLVerifyClient) вызов идет нормально, но я не думаю, что это правильный путь.

Любые предложения по этой теме были бы очень полезны.

Судя по ошибке, приложение на их стороне основано на Java. Я могу ошибаться здесь, это вид мое первое родео. Но могло ли случиться так, что со своей стороны им нужно импортировать свой CA в свое хранилище ключей Java?

Я помню, как настраивал надежное (безопасное) соединение между Java-приложением (Atlassian Crowd) и новым сервером LDAP. Сервер LDAP также использовал самозаверяющий сертификат. Это приведет к сбою с аналогичной ошибкой. Ответ заключался в том, чтобы импортировать сертификат в хранилище ключей Java.

HTH