Я хочу принудительно выполнить проверку ssl-клиента для одного из моих виртуальных хостов. Но выдает ошибку «Не был отправлен требуемый сертификат SSL» при попытке ПОЛУЧИТЬ что-то от него.
Вот мои тестовые конфиги:
# defaults
ssl_certificate /etc/certs/server.cer;
ssl_certificate_key /etc/certs/privkey-server.pem;
ssl_client_certificate /etc/certs/allcas.pem;
server {
listen 1443 ssl;
server_name server1.example.com;
root /tmp/root/server1;
ssl_verify_client off;
}
server {
listen 1443 ssl;
server_name server2.example.com;
root /tmp/root/server2;
ssl_verify_client on;
}
Первый сервер отвечает кодом 200 http, но второй возвращает «400 неверный запрос, не был отправлен требуемый сертификат SSL, nginx / 1.0.4».
Наверное, нельзя использовать ssl_verify_client на одном IP? Должен ли я привязать эти серверы к разным IP-адресам, решит ли это мою проблему?
Я столкнулся с подобной проблемой, но хотел различить ssl_verify_clients между блоками местоположения внутри серверного блока, а не между серверными блоками. Вероятно, вы могли бы решить свою проблему, переместив конфигурационный файл ssl по умолчанию на два сервера (дублируя его, конечно, или поместив их все в один серверный блок, приняв несколько поддоменов и используя местоположения).
Для решения на основе местоположения, похоже, следующие работы. Использовать
ssl_verify_client optional;
в серверном блоке и используйте операторы if в различных местах, например:
if ($ssl_client_verify != SUCCESS) {
return 403;
}
Мне нужно было сделать это, чтобы предоставить администратору доступ к веб-приложению, но при этом разрешить веб-перехватчики из github без предоставления github сертификата ssl клиента.
Вам необходимо обновить как минимум до nginx> = 1.0.9, если вы хотите иметь несколько виртуальных хостов на основе имен (с использованием SNI) на одном IP-адресе и порте, но с разными ssl_verify_client настройки для этих хостов.
В более старых версиях nginx ssl_verify_client настройка виртуального хоста по умолчанию использовалась для всех других виртуальных хостов на основе имен в той же комбинации IP + порт. Некоторые другие варианты SSL (ssl_verify_depth, ssl_prefer_server_ciphers) также обрабатывались таким же образом. Использование отдельного IP-адреса или порта может быть обходным решением, если вы абсолютно не можете выполнить обновление.
Заметка от nginx журнал изменений для 1.0.9:
*) Bugfix: the "ssl_verify_client", "ssl_verify_depth", and
"ssl_prefer_server_ciphers" directives might work incorrectly if SNI
was used.
Соответствующие изменения в исходнике nginx: r4034 в багажнике, r4246 в ветке 1.0.
Вы загрузили в свой браузер сертификат клиента (в формате PKCS12), подписанный центром сертификации "/etc/certs/allcas.pem"? В Firefox вы можете проверить сертификаты своих клиентов, перейдя в «Настройки» -> «Дополнительно» -> «Шифрование» -> «Просмотреть сертификаты» -> «Ваши сертификаты».
Значение параметра «ssl_verify_client», если «выключено» по умолчанию. Вы также можете использовать значение «optional», если сертификат клиента SSL не является обязательным.
Я не эксперт по nginx, но видел похожие проблемы с apache с использованием SSL и виртуальных хостов. Проблема заключается в порядке, в котором сервер обрабатывает согласование SSL, а не в выборе виртуального хоста. Первый шаг - установить зашифрованное соединение, и только после этого сервер видит, какое имя хоста вы запрашиваете. И до тех пор, пока он не узнает, он будет использовать настройку по умолчанию - в данном случае это первый хост, которому требуется сертификат клиента для установки SSL-соединения.
Итак, короткий ответ - в этом случае лучше иметь либо отдельные порты, либо отдельные IP-адреса.
Я столкнулся с той же проблемой и нашел решение.
Пожалуйста, попробуйте добавить default_server флаг для второго сервера
listen 443 ssl default_server;