Директива 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

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

Источник

1 ответ

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

nginx: [emerg] no ssl_client_certificate for ssl_client_verify

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

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

Например:

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

Запуск в вашей конфигурации nginx покажет в ответе данные, аналогичные приведенным ниже (значение IMO ограничено значением для устранения неполадок):

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 не являются "релевантными для безопасности" (если контекст является веб-службой, ориентированной на Интернет).

Источник
Другие вопросы по тегам