Меню Рубрики

Установка клиентского сертификата ssl

Часть 2. Установка SSL-сертификатов для клиента и сервера и ограничение доступа к Web-сайту на стороне сервера

Серия контента:

Этот контент является частью # из серии # статей: SSL-сертификаты Web-сайтов и их применение

Этот контент является частью серии: SSL-сертификаты Web-сайтов и их применение

Следите за выходом новых статей этой серии.

Наиболее распространённой областью применения SSL-сертификатов является защита HTTP-трафика, для чего сертификат устанавливается на Web-сервер и используется для шифрования трафика между сервером и клиентом. Корпоративная почта и системы групповой работы, системы хранения документов и всевозможные Web-приложения — все они нуждаются в защите HTTP-трафика.

Поэтому защита внутренних ресурсов обычно начинается с внедрения корпоративных SSL-сертификатов. В данной статье описывается процесс установки сертификата для сайта, активации сертификата в Web-браузере клиента и ограничения круга пользователей, которым разрешается посещать Web-сайт.

Установка серверного сертификата

Часто используемые сокращения.

  • SSL — уровень защищенных сокетов (secure socket layer);
  • CA — удостоверяющий центр (center of authority);
  • CSR — запрос на сертификацию (certificate signing request);
  • CRL — список отозванных сертификатов (certificate revocation list);
  • PKCS — криптографические стандарты с открытым ключом (public-key cryptography standards);
  • CN — общие данные (common name).

Для того, чтобы к Web-сайту можно было обращаться по протоколу HTTPS, на нем должен быть установлен собственный сертификат. «Собственный» означает, что имя сайта, используемое клиентами для обращения к сайту, совпадает с именем, указанным в поле CN сертификата. Однако, так как по требованиям протокола SSL комбинация «адрес:порт» должна быть уникальной, то установить несколько различных виртуальных серверов (с различными сертификатами) на один порт 443 не получится, и для каждого сервера потребуется выделить отдельный порт и указать его при описании данного сервера.

Процесс создания SSL-сертификата для сервера описывался в предыдущей части статьи. Поэтому предполагается, что серверный сертификат уже создан и подписан в корпоративном СА, а также имеются файлы myfile.key и myfile.crt, соответствующие ключу и сертификату сайта. Но до того, как клиенты Web-сайта смогут начать ими пользоваться, эти файлы потребуется подключить к Web-серверу (в рамках данной статьи используется Wеб-сервер Apache) через конфигурационный файл виртуального сервера (или корневого сайта) как показано в листинге 1:

Листинг 1. Подключение SSL-сертификатов

В листинге 1 приведены только параметры (директивы конфигурации Apache), относящиеся к SSL-сертификатам, поэтому для полноценной конфигурации потребуется указать и другие параметры. Указанные директивы записываются в блоке (для виртуального сервера) или в конфигурационном файле корневого сервера (для стандартного Web-сервера).

В данном примере выполняется включение SSL (1-ая строка), на 2-ой строке происходит отключение слабой и небезопасной версии 2.0 протокола SSL. Затем на 3-ей строке устанавливаются параметры защищенного соединения, которые могут использоваться (какой набор параметров будет выбран, зависит еще и от подключающегося клиента). На строках 4 и 5 указываются SSLCertificateFile и SSLCertificateKeyFile – пути к файлу c SSL-сертификатом и к файлу с ключом сертификата.

Для нормальной работы SSL необходимо, чтобы имя сервера, прописанное в директиве ServerName, совпадало с именем, указанным для поля CN в процессе создания сертификата. Если это правило не выполняется, то при обращении к сайту Web-браузер будет постоянно отображать страницу с предупреждением.

Важное примечание: проверяется именно директива ServerName, а не директива ServerAlias. Если для сервера необходимо указать несколько имен, то их можно прописать в директиве ServerAlias.

Установка сертификата в Web-браузер пользователя

Тем не менее при первой попытке войти на сайт, где установлен SSL-сертификат, подписанный корпоративным СА, все равно возникнет ошибка, так как Web-браузер будет утверждать, что возникла критическая ситуация и это поддельный сертификат. В Web-браузере Google Chrome будет отображена страница красного цвета во весь экран, а в Mozilla Firefox – желтого, при этом обе страницы будут предупреждать пользователя, что произошел критический сбой в системе безопасности, как показано на рисунках 1 и 2.

Рисунок 1. Отображение неизвестного сертификата в Google Chrome

Рисунок 2. Отображение неизвестного сертификата в Mozilla Firefox

Web-браузеры выводят сообщения, изображенные на рисунках, так как не могут проверить, какая организация подписала данный сертификат. Как уже упоминалось в прошлой части, система CA – иерархическая, и сертификаты корневых СА распространяются вместе с Web-браузерами. В Google Chrome используется хранилище сертификатов Windows, и его список корневых сертификатов может измениться после установки пакета с обновлениями от Microsoft, а в Mozilla Firefox используется собственное хранилище сертификатов.

Поскольку данный сертификат подписан внутри самой организации, то её корневой сертификат у Web-браузера, конечно, отсутствует, и он считает, что произошла ошибка. Чтобы исправить эту ошибку, достаточно просто распространить на все компьютеры в локальной сети сертификат корпоративного СА (файл caserv.crt) ещё до того момента, как пользователи начнут обращаться к корпоративным Web-ресурсам по протоколу HTTPS. Этот сертификат потребуется установить в системное хранилище Windows и в хранилище Firefox (а если используется еще и Web-браузер Opera, то и в его собственное хранилище).

Процесс установки сертификата не представляет особой сложности, однако система несколько раз уточнит: действительно ли можно доверять этому издателю сертификатов. Также необходимо обратить внимание, куда именно будет установлен сертификат: он должен быть установлен в «Доверенные Корневые Центры Сертификации», а не в какую-либо другую группу.

Преобразование SSL-сертификата из одного формата в другой

Установка корневого сертификата на мобильное устройство (например, смартфон Nokia N95 8G) требует значительно больше усилий, так как смартфон не понимает текстовых сертификатов (формат PEM). Поэтому в данном разделе рассматривается процесс перекодирования сертификата из одного формата в другой.

Существуют два стандартных формата для хранения сертификатов — PEM (текстовый) и DER (двоичный). С точки зрения содержания они не отличаются друг от друга, но текстовый формат разработан так, чтобы его можно было просматривать в текстовых редакторах и без проблем пересылать по почте. Отличие между форматами состоит в степени их поддержки различными устройствами, так как формат PEM поддерживается далеко не всеми устройствами. Поэтому для установки корневого сертификата СА на устройство, которое не поддерживает формат PEM, его потребуется предварительно перекодировать.

Перекодирование сертификата из формата PEM в формат DER выполняется следующей командой:

Расширение файла (.cer) – это стандартное расширение для сертификатов формата DER. Этот формат поддерживается большим числом оборудований, в частности, упомянутым выше смартфоном Nokia N95 8G. Обратное преобразование из формата DER в формат PEM выполняется сходным образом:

Для обратного преобразования в команде достаточно просто поменять порядок аргументов, но полученный таким образом PEM-файл не будет содержать текстовой части (содержимое сертификата, пригодное для просмотра человеком), поэтому для создания сертификата с заполненной текстовой частью используется другая команда:

Читайте также:  Установка бетонных блоков на дороге

Если же, наоборот, необходимо удалить из сертификата текстовую часть, то используется следующая команда:

Сертификат корпоративного СА, перекодированный в формат DER, переносится на смартфон и устанавливается способом, специфичным для конкретного мобильного устройства.

Установка SSL-соединения с Web-сайтом

После того, как сертификат корпоративного СА установлен в качестве корневого, Web-браузеры распознают сертификаты, подписанные им, и больше не выводят страниц с предупреждениями, а сразу устанавливают соединение с запрошенным ресурсом, как показано ниже.

Рисунок 3. Установленное SSL-cоединение в Google Chrome

Рисунок 4. Установленное SSL-cоединение в Mozilla Firefox

При выполнении подключения к Web-сайту с установленным SSL-сертификатом дополнительно могут проверяться следующие параметры: дата начала и окончания срока действия сертификата. Если дата начала срока действия еще не наступила или наоборот, дата окончания срока действия уже прошла, то сертификат, независимо от наличия установленного корневого сертификата CA, будет объявлен ошибочным.

Также может быть проверено, не отозван ли данный сертификат. Как было упомянуто в предыдущей статье, система должна иметь возможность блокировки сертификатов, которые были выданы людям, на данный момент покинувшим организацию. Поэтому в сертификат можно добавить параметры, которые будут распознаваться Web-браузерами. На основании полученной информации Web-браузер сможет загрузить с указанного адреса CRL и проверить, не входит ли сертификат, используемый для подключения, в список отозванных. Если этот сертификат присутствует в списке отозванных, то соединение будет заблокировано.

Важное примечание: ссылка на CRL должна указываться и в параметре CRLDistributionPoint (как определено в новой версии стандарта), так и в параметре nsCaRevocationList — именно этот параметр считывается многими Web-браузерами, и при его отсутствии возникают сообщения об отсутствующем списке CRL и т.д.

Ограничение возможности подключения для нежелательных клиентов

Посторонние пользователи не должны иметь доступ к корпоративной Intranet-сети — это совершенно очевидно. Поэтому, чтобы иметь возможность управлять клиентскими подключениями с помощью серверного SSL-сертификата, в конфигурационный файл виртуального сервера необходимо добавить строки, приведенные в листинге 2.

Листинг 2. Добавление ограничений на подключение клиентов

Параметры SSLCertificateChainFile и SSLCACertificateFile задают сертификат корпоративного СА, параметр SSLCARevocationFile определяет путь к CRL, а параметр SSLVerifyClient активирует проверку клиентского сертификата. В этом примере вводится самое простое ограничение: к сайту смогут подключиться только те пользователи, у которых на компьютерах установлен клиентский сертификат, подписанный корпоративным СА. При этом никаких дополнительных проверок выполняться не будет, если на клиентском компьютере, осуществляющем подключение к серверу, отсутствует клиентский сертификат, то в установке подключения будет отказано, как показано ниже.

Рисунок 5. Страница с сообщением об отказе в подключении в Google Chrome

Рисунок 6. Страница с сообщением об отказе в подключении в Mozilla Firefox

Если простого условия о наличии SSL-сертификата, подписанного корпоративным СА недостаточно, то на основе параметра SSLRequire можно реализовать более сложные проверки, которые будут учитывать различные параметры сертификата.

Существует еще одна проблема, связанная с задачей организовать доступ к Web-ресурсу с контролем доступа по сертификатам, когда этот Web-сайт не обладает подобной функциональностью. Простым перенаправлением HTTP-запросов на страницу авторизации эту проблему не решить, так как клиент сможет заходить на Web-ресурс напрямую по его внутренним ссылкам, минуя страницу авторизации.

В данном случае может пригодиться такой прием, как «обратное проксирование», при котором, как и в случае обычного проксирования, есть некоторая программа, работающая на сервере и получающая запросы с одной стороны, а затем транслирующая их на другую. При этом достаточно установить защищенное соединение только с самим прокси-сервером, соединение между прокси-сервером и защищенным Web-сайтом может выполняться и без шифрования.

Заключение

C точки зрения организации безопасной ИТ-среды Web-ресурсы любой компании в первую очередь нуждаются в защите HTTP-трафика, причем, как правило, необходимо не только сгенерировать ключи для всех используемых серверов, но и организовать их разделение по портам, так как из-за требований протокола HTTPS на одном физическом сервере на одном и том же порту нельзя разместить несколько виртуальных Web-серверов с поддержкой HTTPS.

Дополнительно следует продумать вопрос, необходимо ли ограничить круг пользователей, которые будут иметь доступ к указанным Web-ресурсам. Если такая необходимость возникнет, то для всех пользователей потребуется сгенерировать клиентские SSL-сертификаты, обеспечить регулярное обновление CRL для отзыва аннулированных сертификатов и активировать поддержку CRL на Web-сайте, доступ к которому должен быть ограничен.

источник

Авторизация с помощью сертификата ssl на nginx + Let’s Encrypt

Добрый день, вечер или ночь, все зависит от времени суток в который вам довелось прочитать мою статью.

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.

Исходные данные:

Сервер с учетной программой + web интерфейс находятся в DMZ;
WEB-server на nginx, на него проброшены порты http(80) и https(443);
На web-server настроен proxy_pass на сервер с учетной программой, доступ только по порту 8080 и только с IP web-server, большего доступа с серверу нет(обычная безопасность);
На сайт для доступа установлен сертификат от Let’s Encrypt.

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

Для сертификатов будем использовать каталог «/etc/ssl/crm.example.ru»

Создаём структуру каталогов:

Создаем конфигурационный файл для подписи сертификатов.

Создаем самоподписанный сертификат и новый ключ сервера без пароля:

Либо, если хотите всё вводить вручную.

Просмотреть данные закрытого ключа и сертификата вы можете с помощью команд:

Создание клиентского закрытого ключа и запроса на сертификат (CSR):

Либо, если хотите всё вводить вручную.

Заместо User example1 можно указать почту клиента, а за место EXAMPLE компанию клиента, это поможет отслеживать сертификаты.

В результате выполнения команды появятся два файла client01.key и client01.csr. Просмотреть данные закрытого ключа и запроса на сертификат (CSR) вы можете с помощью команд:

Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA). При подписи запроса используются параметры заданные в файле ca.config

Читайте также:  Установка flash плагина для просмотра

Подготовка данных для передачи клиенту. Для передачи полученных в результате предыдущих операций файлов клиенту, обычно используется файл в формате PKCS#12. В этот файл упаковывается и защищается паролем вся информация необходимая клиенту для инсталляции сертификата в броузер.

Выставляем права доступа на ключи.

Переместим все созданные файлы в каталог db/certs на хранение.

Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл client01.p12 и ca.crt, а так же сообщить пароль для установки сертификата. ca.crt необходим, так как мы не используем его для сертификации сервера, для этомо используеться Let’s Encrypt.

Процесс выдачи сертификатов можно автоматизировать, написать просто скрипт не составит труда. У нас таких клиентов не много, около 15, так что вбить всё руками не составило проблем.

источник

Авторизация клиентов в nginx посредством SSL сертификатов

Введение:

Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.

Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.

Внимание! В статье для примера используются самоподписанные сертификаты!

Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:

Шаг 1. Создание собственного самоподписанного доверенного сертификата.

Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.
С помощью приведенной ниже команды создается закрытый ключ и самоподписанный сертификат.

req Запрос на создание нового сертификата.
-new Создание запроса на сертификат (Certificate Signing Request – далее CSR).
-newkey rsa:1023 Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.
-nodes Не шифровать закрытый ключ.
-keyout ca.key Закрытый ключ сохранить в файл ca.key.
-x509 Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.
-days 500 Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.
-subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com
Данные сертификата, пары параметр=значение, перечисляются через ‘/’. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc». Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx».

Шаг 2. Сертификат сервера

Создадим сертификат для nginx и запрос для него

Подпишем сертификат нашей же собственной подписью

Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата

Конфиг nginx

теперь сервер готов принимать запросы на https.
в переменных к бекенду появились переменные с информацией о сертификате, в первую очередь SSL_VERIFIED (принимает значение SUCCESS).

Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:

Что ж, логично, в этом-то и вся соль!

Шаг 3. Создание клиентских сертификатов

3.1 Подготовка CA

Создадим конфиг
nano ca.config

Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле

3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)

Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи. Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата, но отсутствует параметр -x509.

В результате выполнения команды появятся два файла client01.key и client01.csr.

3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

В результате выполнения команды появится файл клиентского сертификата client01.crt.

Для создания следующих сертификатов нужно повторять эти два шага.

3.4. Создание сертификата в формате PKCS#12 для браузера клиента

Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.

3.5 Подключение к полученному ssl cерверу с помощью curl

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

Использованное ПО

Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010

Полезные ссылки

Надеюсь, был кому-то полезен.

P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Настраиваем HTTPS-сервер на nginx

Nginx как Reverse Proxy для сайта, использующего SSL

Установка StartSSL сертификатов — Postfix/Dovecot/Nginx

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 31

Ну, во-первых, с openssl поставляются скрипты, делающие почти всю черную работу за вас.

В файле конфигурации сертификатов (как правило, файл называется openssl.cnf , в вашем случае ca.conf , кстати, тоже непонятно, зачем придумывать стандартным конфигам свои имена файлов) была отмечена опция default_crl_days = 7 как Срок действия CRL . Но, при этом, остальные опции CRL отсутствуют (например, директория отозванных сертификатов, следующий порядковый номер отзыва) и, вообще в статье не отмечена очень важная возможность отзывов сертификатов.

Возможно (тьфу-тьфу), если из вашей компании кто-нибудь когда-нибудь уволится, не настроив openssl с самого начала, у вас возникнут проблемы. Предлагаю вам разобраться в CRL и дополнить статью!

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

Спасибо за внимательность!

Дописать в том же духе за давностью лет тяжело, поэтому добавлю в комментарии, а не в основной текст:

в nginx можно дописать опцию проверки отозванных сертификатов, выглядит она вот так:

Как сгенерировать файл с отозванными сертификатами статьи уже есть и не одна.

Ну вы просто не забудьте отметить этот тонкий момент. Потому что про него все забывают и нигде заранее не пишут. Я не пользовался Ubuntu, осваивал openssl на FreeBSD 6 по исходникам. А первый раз получил задание от директора отозвать сертификат менеджера за то время, пока тот не добежит бегом до компьютера, чтобы не слить клиентскую БД. Обычно, в случаях отзывов сертификатов, счет идет на секунды! Важно готовить скрипты заранее, чтобы можно было из любого окна терминала ограничить доступ любому сертификату.

Читайте также:  Установка био для очистки сточных вод

А если вы не подготовите команды или скрипты заранее, возможна и такая ситуация, когда надо будет переделывать все сертификаты из-за того, что не могли отозвать один.

Будет, если есть сертификаты, подписанные теми CA, которые указаны в рамках секции Certificate Request в server hello.

Т. е., если у пользователя нет сертификатов, подписанных теми CA, которые указаны в ssl_client_certificate , то в firefox и chrome (по крайней мере, на современных) пользователь не получит запроса на указание сертификата. Иначе — попросят указать сертификат (или отказаться, но тогда для входа по сертификату придется перезапустить браузер или зайти в порно-режиме).

Потому и говорю, что костыли.

Смотрим в https://tools.ietf.org/html/rfc5246#section-7.4.4 и видим, что в CertificateRequest отправляется набор DN ов CA. Так что если DN вашего самоподписанного CA будет тупо /CN=Example CA или /CN=Root CA, то проблемы будут.

Название distinguished name кагбэ говорит, что оно должно быть отличным от других (уникальным).

А через curl работает? Корневой сертификат, которым подписан клиентский сертификат, добавлен в конфиг nginx как опция ssl_trusted_certificate / ssl_client_certificate ?

Вот пошаговый мануал: по факту нужно не 14 файлов, а меньше: ключевая пара удостоверяющего центра, ключевая пара сервера, ключевая пара клиента и конфиг Nginx. 7 🙂

Создание сертификата сервера

Конфигурационный файл server.cnf , пример:

В subjectAltName должны быть указаны все используемые DNS-имена и IP-адреса.

Создание запроса на сертификат

Настройка Nginx, пример (фрагмент)

Создание сертификата клиента

Следующая команда должна отрабатывать без ошибок:

Следующая команда должна возвращать ошибку «не предоставлен сертификат клиента»:

Добавление сертификата ЦА в RHEL (от имени root , где path/to/ca.crt — путь к файлу корневого сертификата)

Последний пункт нужен, чтобы можно было не указывать явно сертификат ЦА в командах (в том же cURL).

Одна маленькая ремарка: лучше в серверном CN указывать хост. В SAN он тоже должен присутствовать, естественно.

Вот уж пару лет развлекаюсь тем, что пихаю в CN надписи на русском (в UTF-8) — пока проблем ни с каким софтом не возникало — все смотрят в SubjectAltNames.
Впрочем, раньше я это делал чисто из эстетических соображений — чтобы видеть эти русские буквы в информации о сертификате, сейчас же, когда в хроме надо пройти целый квест, чтобы эту информацию увидеть, большая часть смысла пропала 🙂

А вы добавляли корневой сертификат в браузер? Т.е. зелёный замочек в браузере есть? Дело может быть в этом. См. https://habrahabr.ru/post/213741/#comment_7814423, например.

В смысле «помогла»? Вы просто выключили эту фичу IIRC

Да, это понятно что выключил… непонятно в чем там кроется собака:) Я уже пересоздал сертификаты, все параметры ввел в cnf и при вводе в консоль одинаковые буква в букву. Есть вот такое обсуждение https://forum.nginx.org/read.php?21,182573,183073#msg-183073 но там предлагают ставить патч.

Но я бы сначала хотел в принципе разобраться что происходит в реальной жизни (когда юзер заходит на сайт по https) и что происходит под локалхолстом с самоподписанным сертификатом.
Как я понимаю, «ca» — это сертификат удостоверяющего центра (в реальной системе у меня его не будет, а будут вшитые в браузер); «server» — это сертификат сервера, то что мне выдадут например на let’s encrypt для моего домена. А что такое сертификат клиента «client»? Откуда он берется в реальных условиях (браузер открывает https ссылку) и почему мы его генерируем для локалхоста?

Если на пальцах, то в случае использования клиентской аутентификации по tls есть две ветки PKI.

  1. Сторона сервера (которая есть и без клиентской authN), которая включает root CA, intermediate CAs и серверный сертификат. При подключении клиента к серверу при установлении соединения сервер отдаёт свой сертификат с реверсной цепочкой не включая CA (т. к. он есть у пользователя). Файл с этими сертификатами в nginx указывается в параметре ssl_certificate .
  2. Сторона клиента имеет независимую ветку PKI (которая может спокойно использовать приватный CA). При включенной ssl_verify_client (необходимо также указать ssl_client_certificate , если используется on или optional ) сервер после ServerHello передаёт дополнительно фрейм Certificate Request , в котором перечислены dn’ы CA которым данный endpoint доверяет в контексте аутентификации клиента (в случае использования optional_no_ca этот список пустой). Клиент на этот запрос предоставляет сертификат (в случае браузера показывает окошко, где пользователь выбирает какой сертификат использовать).

И первая ветка PKI (серверная) в нормальном случае получается через публичный CA типа LetsEncrypt. Сторона же пользователя, в зависимости от сервиса может получаться:

  • от публичного или государственного CA,
  • от приватного CA самого сервиса (который, по сути, в статье и описан).

Если хочется разобраться, то рекомендую взять для начала wireshark, открыть rfc5246, выполнить описанное в 3 части статьи.

Я для тестов использовал сейчас более простую конфигурацию:

Для отладки ssl/tls chrome (и, вроде, ff) поддерживают переменную окружения SSLKEYLOGFILE , в которой указывается файл куда сохранять сессионные ключи. Эту переменную можно использовать только при отладке. При наличии этого файла кто угодно может расшифровать содержание SSL/TLS сессий (в том числе при использовании PFS).

Я использую следующий скрипт-обёртку:

Путь к этому файлу нужно указать wireshark’у в preferences -> protocols -> ssl, пункт (Pre)-Master-Secret log filename .

Вот ещё хорошая статья, если хочется знать, что там под капотом и как работает: https://tls.dxdt.ru/tls.html

Ещё могу посоветовать стэнфордский курс Crypto на Coursera — хорошо объясняют про криптографию в целом (но уже чёрт знает сколько лет не могут выпустить вторую часть курса).

3.5 Подключение к полученному ssl cерверу с помощью curl

curl -k —key client.key —cert client1.crt —url «https://site.com»

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

а известно как аутентифицировать пользователя по его (клиентскому) сертификату?
Т.е. подписали мы клиентских сертификатов, сервер их пускает, но нам нужно определить кто есть кто

в IIS, знаю, это настраивается так…
есть что-то подобное для nginx?

источник