Взаимная аутентификация на NGINX (OpenSSL).

Иерархия должна быть такова:

А это еще нафига? В смысле, это ж совершенно бредовое требование.

Так поставлена задача.

то есть клиент не доверяет промежуточным уц?

А что в данном случае считать промежуточным CA?

Насколько я понял из стрелочек, вы клиентский сертификат подписываете ключом сервера, а для этого в политиках применения сертификата сервера должно быть указано подписывание клиентских ключей, такую хрень обычно никто не делает и в примерах команд openssl не указывает. При этом я не уверен, что клиент обязан доверять промежуточному УЦ, которым является сервер, при наличии доверия только к корневому УЦ.

Если у клиента есть доверие к корневому центру, то он может построить цепочку к серверному. Как в политиках применения серверного сертификата настроить подписание клиентских?

Если у клиента есть доверие к корневому центру, то он может построить цепочку к серверному.

не факт, зависит от клиента

Как в политиках применения серверного сертификата настроить подписание клиентских?

воспользуйтесь документацией к своему УЦ. Но я категорически не рекомендую так делать, ибо утечка ключевой информации сервера, приведёт к печальным последствиям.

пупетообразную поделочку делаете?

не факт, зависит от клиента

То есть?

утечка ключевой информации сервера, приведёт к печальным последствиям.

Компрометация корневого УЦ тоже.

пупетообразную поделочку делаете?

Это что такое?

То есть?

то есть длину цепочки доверия можно указать или она захардкодена

Компрометация корневого УЦ тоже.

корневой УЦ, как правило, либо вообще из сети не доступен, либо очень сильно огорожен, а обычный сервер — выставляют наружу для работы кого-то из сети или интернета с чем-то на этом сервере

Это что такое?

google://puppet

Это у меня лабораторная такая.

Длина цепочки доверия такая, какую я указал.

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

Ещё добавлю, что в качестве надстройки над openssl для лаб и мелочей незазорно использовать гуй xca

Я пытался. Но аутентификация не проходит, хотя в атрибутах всех сертификатов все издатели указаны точно.

http://www.carbonwind.net/VPN/XCA_OpenVPN/xca_new_cert_ca_5.png

вот эти выделенные поля надо добавить в серт сервера

Спасибо, попробую.

Ваш способ не пробовал, но в атрибутах уже созданного сертификата в KeyUsage уже есть Certificate Sign и SRL Sign.

а политики ссл-сервера стоят?

Какие именно и где? Я спрашиваю потому, что раньше с сертификатами мало работал.

в той же вкладке и в следующей

Чтобы было понятнее, выложу куски конфигов для генерации сертификатов.

Секция для подписания сервера

[ v3_ca ]

basicConstraints = critical, CA:true, pathlen:0 nsCertType = sslCA keyUsage = cRLSign, keyCertSign extendedKeyUsage = serverAuth, clientAuth nsComment = «OpenSSL CA Certificate»

Секция для подписания клиента

[ v3_req ] basicConstraints = CA:FALSE keyUsage = cRLSign, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth

в глазах рябит, но выглядит всё как надо. Как бы не оказалось, что это фундаментальное ограничение.

Как бы не оказалось, что это фундаментальное ограничение.

В смысле?

в смысле, нельзя иметь в одном серте УЦ и политики относящиеся к конечному пользователю, пойду рфц почитаю

В результате у меня генерятся 3 сертификата: ca.crt, server.crt, client01.crt (привожу в иерархическом порядке).

Сливаю сертификаты: cat server.crt ca.crt > serverCert.crt

получаю слитый сертификат сервера;

cat client01.crt serverCert.crt> clientCert.crt

получаю слитый сертификат клиента.

В конфиге NGINX прописываю

server{

listen 443;

ssl on;

ssl_certificate /etc/nginx/ssl/Task8/config/serverCert.crt;

ssl_certificate_key /etc/nginx/ssl/Task8/config/server.nopass.key;

ssl_client_certificate /etc/nginx/ssl/Task8/config/serverCert.crt;

ssl_verify_client on;

ssl_session_timeout 5m;

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:1m;

ssl_ciphers ALL:!ADH:! EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL;

......

}

У тебя в политике использования сертификата сервера нет разрешения подписывать сертификаты. Вообще левая идея, но дело хозяйское

У тебя в политике использования сертификата сервера нет разрешения подписывать сертификаты

Я прописал basicConstraints = critical, CA:true

Вообще левая идея, но дело хозяйское

Левая идея строить такую иерархию?

Я прописал basicConstraints = critical, CA:true

Ну, ты прописал, а в сертификате по факту что?

Левая идея строить такую иерархию?

Ага

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

Левая идея строить такую иерархию?

ловко ты заметил в конце дня, хорошо

Ну, ты прописал, а в сертификате по факту что?

x509v3 basicConstraints CA:TRUE

В Винде «Использование ключа: Подписывание сертификатов, Автономное подписание списка отзыва (CRL), Подписывание списка отзыва (CRL) (06)»

А идея не моя, мне дали такое задание.

Залей куда-нибудь эти твои сертификаты, посмотрим

ловко ты заметил в конце дня, хорошо

Это обсуждалось еще в самом начале темы. Я заметил это уже давно. Я пытался сдать работу, в которой сертификаты и сервера, и клиента подписывались сертификатом корневого УЦ. Но получил задание переделать.

Сертификаты

http://rusfolder.com/39702611 http://rusfolder.com/39702612 http://rusfolder.com/39702613

а можно полностью задание?

cat client01.crt serverCert.crt> clientCert.crt

Это не нужно.

ssl_client_certificate /etc/nginx/ssl/Task8/config/serverCert.crt;

Ага:

This directive specifies the file containing the CA (root) certificate, in PEM format, that is used for validating client certificates.

root, а не intermediate, как у тебя.
И все-таки, откуда такая дурацкая постановка задачи и почему постановщику нельзя, обидно хохоча, пояснить его неправоту?

Настроить связку Apache2+Nginx, настроить взаимную аутентификацию на Nginx. Иерархия сертификатов: сертификат корневого CA -> сертификат сервера -> сертификат клиента.

препод он, нельзя ему хохоча объяснять, надо заставить сервер быть помежуточным УЦ

препод он

Я думал об этом и теперь все больше склоняюсь к мысли о студенте, который неправильно понял задание.
Кроме того, в природе встречаются (раньше встречались, по крайней мере) вменяемые преподы, которые умели принять указание на собственную неправоту. Ну, обидный хохот, конечно, придется из пояснений исключить.

я тоже думаю, что он неправильно задание понял, потому прошу его полностью озвучить. Будет пичяльно если на самом деле препод — бревно.

root, а не intermediate, как у тебя.

И как выходить из ситуации?

пояснить его неправоту

Нужны аргументы. Много веских аргументов. Доводы, что так обычно не делают, могут не сработать.

Иерархия была даже нарисована на бумаге.

Аргументы? Вот тебе ситуация: твой препод приходит в банк просить кредит на покупку новых носков.
Должна ли банковская чувиха, проверяющая его паспорт, быть заведующей паспортного стола, который когда-то ему этот паспорт выдал?

Стоит ли этой банковской чувихе выдавать привилегии нагенерить любое количество паспортов с этими же именем и фамилией на любое количество произвольно взятых людей?

Хреново, раз так.
Зови сюда декана, чо.

Ты в коллекцию с клиентским сертификатом CA не забыл положить?

Офигенный пример. Наглядный.

А можно еще доводов. Чисто технических.

И как выходить из ситуации?

Ну написано root - подложи ему root.

Разграничение прав - вот тебе технический довод.
Админ вебсервера в твоей схеме может генерить сертификаты клиентов. А это работа не его, а админа PKI.

Не работает.

ssl on; ssl_certificate /etc/nginx/ssl/Task8/config/serverCert.crt; ssl_certificate_key /etc/nginx/ssl/Task8/config/server.nopass.key; ssl_client_certificate /etc/nginx/ssl/Task8/config/ca.crt; ssl_verify_client on;

А это работа не его, а админа PKI

А их можно совместить?