Директива nginx ssl_trusted_certificate не работает

Когда я пытаюсь запустить сервер nginx с этой конфигурацией, я получаю сообщение об ошибке

nginx: [emerg] no ssl_client_certificate for ssl_client_verify

Моя конфигурация выглядит так

# HTTPS server
server {
    listen       4443;
    server_name  localhost;
    ssl                  on;
    ssl_certificate      /home/user/conf/ssl/server.pem;
    ssl_certificate_key  /home/user/conf/ssl/server.pem;
    ssl_protocols        TLSv1.2;

    ssl_verify_client optional;
    ssl_trusted_certificate /home/user/ssl/certs/certificate_bundle.pem;

    include conf.d/api_proxy.conf;
}

В соответствии с ошибкой я должен использовать директиву ssl_client_certificate, но согласно документации, если я не хочу отправлять список сертификатов клиентам, я должен использовать ssl_trusted_certificate.

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Может ли кто-нибудь помочь мне понять, что мне не хватает?


nginx nginx-reverse-proxy nginx-location nginx-status
person user1918858    schedule 17.04.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Ответ находится в самом сообщении об ошибке:

nginx: [emerg] no ssl_client_certificate for ssl_client_verify

Если вы отключите ssl_client_verify в своей конфигурации, ошибка исчезнет при следующем запуске nginx. Похоже, что семантика ssl_trusted_certificate относится только к его исключительному использованию и подлежит логическому переопределению, когда действуют другие директивы конфигурации.

Я лично предпочел бы, чтобы включение ssl_client_verify означало: клиентские сертификаты проверяются, если они представлены; клиентам не предоставляется информация о том, каким клиентским сертификатам или полномочиям доверяет веб-сервер. Но я также вижу преимущество в устранении неполадок с рукопожатиями TLS, когда эта информация доступна. С точки зрения безопасности я вижу только метаданные, представленные клиенту через openssl s_client; нет открытого ключа или другой критической для подписи информации, которую злонамеренный клиент мог бы использовать, например, для попытки клонировать/реконструировать ЦС.

Например, запустив следующее на локальном экземпляре nginx с вашей конфигурацией:

openssl s_client -key client.key -cert client.crt -connect localhost:443

... будет отображать в ответе данные, похожие по структуре на следующие:

Acceptable client certificate CA names
/CN=user/OU=Clients/O=Company/C=Location
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits

На мой взгляд, ценность вышеизложенного ограничивается устранением неполадок.

Ваши структуры DN (в идеале) не имеют отношения к безопасности (особенно если контекст представляет собой веб-службу с выходом в Интернет).

person mxmader    schedule 07.09.2018