Я выполнил инструкции в это сообщение в блоге, но когда я тестирую его с curl, nginx's $ssl_client_verify переменная всегда NONE. По факту, curl даже не дает другого вывода, когда я не указываю --cert и --key варианты вообще. Как будто он игнорирует мои сертификаты. Как я могу это отладить?
Я даже попытался сделать так, чтобы все эти места имели одинаковую ценность:
Если под «Common Name» в сертификатах CA и Server вы имеете в виду полное имя Subject, которое может содержать другие элементы, кроме Common Name, хотя большинство людей, использующих специальные сертификаты SSL, как этот, не беспокоятся о них, это то же самое - не не делай этого. OpenSSL, который используют и nginx, и curl, не может связать дочерний сертификат с родительским сертификатом с таким же именем; это не нормальный случай для X.509 и, по крайней мере, в общем случае может не обрабатываться и в другом программном обеспечении.
Я считаю, что это должно сработать. Более простой и, вероятно, лучший инструмент тестирования - это командная строка openssl:
openssl s_client -connect $addr:$port -cert $clicert -key $clikey -CAfile $cacert
который выведет подробную информацию о (предпринятом) подключении SSL / TLS. Если ближе к концу он говорит Acceptable client certificate CA names за которым следует правильное имя вашего CA, сервер правильно настроен для аутентификации клиента (а также для базового SSL). Если у него другое имя или написано No client certificate CA names sent, что-то не так. когда s_client ждет ввода, просто введите EOF (Unix обычно ^ D, Windows ^ Z).
Кроме того: веб-сайт неправильно говорит, что подписание запроса сервера с помощью созданного вами специального ключа CA & cert является «самоподписанием». Самоподпись - это, в частности, подписание сертификата той же парой ключей, публичная половина которой в этом сертификате; на практике это используется только для CA верхнего уровня, называемого «корнем». Вы подписываете сертификат сервера своим собственным ЦС, но не подписываете самостоятельно. Подписывать сертификат сервера с помощью собственного центра сертификации - это плохо, если вы хотите обрабатывать соединения из посторонние люди потому что он не предоставляет им никаких доказательств доверия вашему серверу, как это делает "коммерческий" сертификат сервера от известного центра сертификации, такого как Verisign или GoDaddy. Это обычно относится к производственной среде, а не к тестированию, поскольку тестирование часто используется только разработчиками и / или несколькими бета-тестерами, но некоторые производственные системы также могут быть ограничены несколькими тесно связанными клиентами.
РЕДАКТИРОВАТЬ: получение специального CA (для клиентских сертификатов), подписанного известным CA: это было бы сложно и дорого, и в этом нет необходимости.
Если известный центр сертификации дает вам сертификат «суб-CA» или «промежуточный CA», позволяющий выдавать сертификаты, они делают ставку на будущее их бизнес на ваш безопасность - либо вы должны обеспечить безопасность на том же уровне, что и они (нестандартное оборудование, специализированные здания, круглосуточная охрана, множественный специально обученный и сертифицированный персонал, регулярные внешние аудиты - все дорого) или вам придется выкупать их бизнес (чтобы они больше не подвергались риску). В дополнение к вашему https://security.stackexchange.com/questions/25551/help-understanding-client-certificate-verification видеть:
Но единственные системы, которые должны доверять сертификатам, которые вы выпускаете своим клиентам, - это ваши собственные серверы; пока вы управляете своими собственными серверами, вы просто настраиваете их так, чтобы они доверяли вашему собственному сертификату CA.
Ага, это Маверикс.
Опция -E / - cert также сломалась.
Если я устанавливаю curl с помощью brew и указываю параметр сборки --openssl, он работает.