Четвёртая часть цикла про свой удостоверяющий центр. В первой мы развернули Root CA и три промежуточных центра, во второй научились отзывать сертификаты и подняли OCSP-responder, в третьей настроили вход по клиентскому сертификату в nginx и Apache. Осталось ответить на вопрос, который возникает сразу после первого успешного входа: а откуда у людей берутся сертификаты?

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

В четвёртой части:

— PKCS#10 прямо в браузере. Ключ рождается в WebCrypto и не покидает его, запрос собирается на голом JavaScript без единой библиотеки, а результат проверяется настоящим openssl, а не «на глаз».

— Почему кнопке «получить сертификат» нельзя доверять отличительное имя: позволь заявителю назвать себя самому — и он выпишет себе сертификат с DN администратора. Настоящий, подписанный вашим же центром.

— PKIDesk: движок управления сертификатами на Go, без единой зависимости, под Apache-2.0. Разрезан по границе доверия — у веб-части нет ни ключей УЦ, ни index.txt, ни даже бинарника openssl. Плюс пять архитектурных развилок, за которые придётся отвечать перед аудитом.

— Три дефекта, которые вылезли только на живом стенде: правило subjectAltName = supplied, которое не выполнится никогда; просроченный сертификат, который остаётся действующим и занимает subject; гонка «выпустил — сразу зашёл», где nginx запоминает неудачную проверку отзыва.

— Четыре расширенных справочника, 237 параметров: openssl req, openssl genpkey, структура PKCS#10 и Web Crypto API — синтаксис, значения, умолчания и подводные камни, сверенные с официальной документацией.

От Root CA до User Authorization в nginx+apache. Часть 4. Свой web-УЦ: выпуск из браузера, роли и аудит