Как правильно выпускать доверенные именные сертификаты в локальной сети с доменом для подписи внутренних документов, например, PDF?

Question

[Дмитрий]

Подскажите пожалуйста, как правильно организовать выпуск доверенных именных сертификатов в локальной сети с AD
для подписи внутренних документов, например, PDF? Я так понимаю, нужно поднять центр сертификации CA, можно его будет поднять на самом КД? Само собой нужна возможность отзыва сертификата, в случае увольнения работника и сам выпуск сертификатов делался бы только администраторами. Заранее спасибо за ответы!

Answer 1

[CityCat4]

Для выпуска своих сертификатов для чего бы то ни было нужен свой CA, конечно же.
Поднять CA на винде можно, но это жутко неудобно, хотя конечно приспособиться можно.
Для подписи документов никогда сертификаты не выпускал, хотя конечно же там нужно только EKU соответствующее.

Comments

[MVV]

Поднять CA на винде можно, но это жутко неудобно

"Вы просто не умеете их готовить". Для CA в AD можно настроить шаблоны сертификатов (многие нужные уже есть) с автоматической или ручной выдачей сертификатов по шаблонами автоматическую подачу заявок на сертификаты.
Для подписи документов нужнj по минимому всего лишь наличие бита digitalSignature в атрибуте KeyUsage (в интерфейсе обычно называется как-то типа "Цифровая подпись" для атрибута "Использование ключа". А нужно ли что-то специфическое в атрибуте EKU - это пот программы зависит. Например, сертификаты для веб-сервера с HTTPS отлично воспринимаются браузерами без EKU вообще.
Короче, автору, скорее всего, подойдет стандартный шаблон Пользователь (User). И для него вполне можно настроить автоподачу заявки. Насколько я знаю, в этом мало что поменялось со времен Win2K3, так что до сих пор можно пользоваться рекомендациями от Vadims Podans

[CityCat4]

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

[Дмитрий]

CityCat4, можно же ведь сделать их резевную копию?

[CityCat4]

Дмитрий, Нет :))) И в этом-то и все дело :) При подаче заявки ключ формируется непосредственно в базе сертификатов внутри винды и его оттуда экспортировать нельзя. Секурность и все такое :) Именно поэтому так страшен BitLocker - проеб машины, ключи пропали, диск превратился в тыкву.

Нельзя достать из базы сертификатов ключ. Ну, обычными средствами, не прибегая к жесткому препарированию. Именно поэтому использование виндового CA возможно только с помощью стороннего софта, который пишет ключи и CSR просто файлами, потом загрузка в веб-морду.

Впрочем, я давным-давно развернул CA на линухе...

[MVV]

CityCat4, ещё раз повторяю: "вы просто не умеете их готовить".
Подпись старым сертификатом проверяется его публичным ключом, содержащемся в сертификате.
Эти публичные ключи содержатся в самих сертификатах. И хранятся, как минимум, на выпускающем CA и вполне доступны через его API. Кроме того, сертификаты пользователя по умолчанию публикуются в AD (там есть для этого специальный атрибут в стандартной схеме, начиная с Win2K3). Где ещё хранятся сертификаты - это зависит от ПО, используемого для создания подписи. Например, в некоторых вариантах септификат может быть встроен в сам подписанный документ (не знаю, правда, возможно ли такое в формате PDF). Ну, а сертификат выпускающего CA, чтобы эти старые сертификат было проверить, тоже нужно хранить где-то ещё. По умолчанию он тоже хранится в AD. Однако для работы со сторонними клиентами, про AD не знающими, он обычно хранится ещё и на веб-ресурсе, URL которого указан в расширении(т.е. поле) AIA выпущенных сертификатов. Но этот URL надо дополнительно указать в настройках CA А вот URL сертификата CA в AD там есть по умолчанию.
Закрытого ключа сертификата на CA может и не быть. И вообще-то, для большинства применений он просто вообще не должен передаваться на CA. Потому что иначе в случае компроментации CA компроментируются все цифровые подписи документов.
Есть правда вариант применения, когда требуется восстановление закрытого ключа - для получения доступа к зашифрованным документам. Такая функция в CA дя Windows тоже есть, и для ее реализации закрытый ключ, естественно, передается. Но он всегда и передается, и хранится в зашифрованном виде, причем, при хранении - шифруется ключом, которого на CA нет. Но для сертификатов, используемых для подписи, требование восстанавливать закрытый ключ - излишнее.
А BitLocker тоже не так страшен, если уметь его готовить. Там на случай аварии можно настроить, к примеру, пароль восстановления, и даже - сохранять информацию для восстановления доступа к диску в AD.
Короче, завязывайте тут с демонстрацией эффекта Даннинга-Крюгера. Я вот, к примеру, не знаю, чем и как реализуются решения тех же самых задач на Linux - вот и не высказываюсь про него. Если вы знаете - опишите вкратце (или дайте ссылки на описание), автору вопроса это может пригодиться. Решение все равно выбирать и реализовывать ему, не нам с вами.

[CityCat4]

ещё раз повторяю: "вы просто не умеете их готовить".

Похоже, мы просто не понимаем друг друга. Общие ключи из пары хранятся где угодно, в AD в том числе. Речь о личном ключе! (о той половине из пары ключ-сертификат, которая не должна быть доступна никому).
Процесс выпуска сертификата вообще я думаю, представляете. Подается заявка на какой-то конкретной машине. Именно на этой машине создается ключ и он там намертво вшивается в хранилище. Заявка выполняется, сертификат выдан, все хорошо.
Далее мы подписали им кучу документов. Далее эта машина сдохла (винт посыпался). Ой, а как же наш сертификат? А он в тыкву, понимаете, превратился...

Я вот, к примеру, не знаю, чем и как реализуются решения тех же самых задач на Linux

Есть предположение, что Вы и про Windows знаете ровно столько же и оснастки CA никогда живьем не видели. А трепаться про расширения сертификата и зачем нужен AIA (а еще есть CDP, а еще есть куча других, не менее полезных вещей) я тоже долго могу. Но проблемы того, что при выпуске сертификата в виндовом CA, если не использовать стороннего софта (чтобы CSR формировался файлом и ключ сохранился файлом) при переустановке винды все подписи (а уж тем паче шифрование документа) превращаются в тыкву потому что ключ шифрования более недоступен...

[MVV]

CityCat4,

Ой, а как же наш сертификат? А он в тыкву, понимаете, превратился...

Не порите чушь - ей больно. Для проверки подписи закрытый кюч не нужен, от слова "совсем". А для создания новых подписей просто создается новый сертификат. У пользователя, понимаете ли, сертификатов может быть несколько - и в соотвествующем атрибуте в AD это учтено: он - многозначный. Для восстановления ключей шифрования в AD CS (это - название для инфраструктуры PKI на базе Windows) централизованный механизм тоже есть, я про него написал выше. И в давние времена - примерно те же, когда Vadims Podans писал про PKI - я его использовал, для реализации S/MIME в связке Exchange/Outlook. Да, восстановить ключ без помощи администратора было непросто (это делалось с командной строки через cerutil), но механизм был и работал.
Но том применении, которое нужно автору вопроса шифрование (и как следствие - восстановление ключей) не требуется.
PS Вообще-то, стандартно в Windows для решения задачи автора есть AD Rights Management Services, но что-то мне подсказывает, что MS не стала заморачиваться созданием клиентов для сторонних систем, так что это решение до сих пор годится только для сетей чисто на базе Windows, и в наше время наличия большого числа мобильных клиентов мало кому подойдет. Поэтому я про нее в ответе даже не упоминал.
PPS

Есть предположение, что Вы и про Windows знаете ровно столько же и оснастки CA никогда живьем не видели.

Вы таки ошибаетесь. Но к сути вопроса этот ваш argumentum ad personam отношения не имеет, так что подробности опускаю. Короче, завязывайте троллить.

[CityCat4]

Для проверки подписи закрытый кюч не нужен, от слова "совсем"

Для проверки подписи - не нужен. Но мы же "за вообще" обсуждать взялись, да?

понимаете ли, сертификатов может быть несколько

Да - внезапно - понимаю :)

Да, восстановить ключ без помощи администратора было непросто (это делалось с командной строки через cerutil), но механизм был и работал.

Замечательно, что мы все-таки пришли к S/MIME :) Но сдох комп, нет его, винт накрылся - откуда восстанавливать?

стандартно в Windows для решения задачи автора есть AD Rights Management Services

Возможно. Давненько как-то делал подход к RMS, но цены кааааак меня укусили...

MS не стала заморачиваться созданием клиентов для сторонних систем

В этой области она много чем не стала заморачиваться. Был Crypto4PKI, но сдох давно

[Дмитрий]

Вообще-то, стандартно в Windows для решения задачи автора есть AD Rights Management Services, но что-то мне подсказывает, что MS не стала заморачиваться созданием клиентов для сторонних систем, так что это решение до сих пор годится только для сетей чисто на базе Windows, и в наше время наличия большого числа мобильных клиентов мало кому подойдет. Поэтому я про нее в ответе даже не упоминал.

А можно тут поподробнее?

[CityCat4]

Дмитрий, О чем поподробнее? Об AD RMS? Есть такая оснастка, компонент System Center, стоит бешеных бабок. Живьем никогда не видел (из-за бабок), но судя по описаниям может дохрена чего.

Неактуально в связи с уходом M$ c рынка.

[Дмитрий]

Всем доброго дня! Если всё таки не усложнять и использовать только штатное решение СА, для надёжности желательно использовать промежуточный ЦС в случае если с корневым что-то случится? Забыл сказать, в сети так же штатно два КД. Вся серверная инфраструктура виртуализирована на VMware, сами ВМ на РАЙДах

[CityCat4]

Дмитрий, Промежуточные CA делают не для чтого, чтобы "что-то случится". Промежуточные CA делают, чтобы снизить риски утечки пароля от корневого ключа. Корневой CA выпускает только подчиненные CA. Их может быть два, три уровня. Если уйдет пароль от ключа CA третьего уровня - ущерб будет не сравним с ущербом от утечки корневого пароля.
Насчет только штатного решения. Хочешь насобирать граблей - ну, вперед! Товарищ MVV мне так и не ответил, что он будет делать в случае, если у него умрет машина с неэкспортированным сертификатом, попробуй ответить ты :)

В чем суть проблемы:
Выпуск сертификата начинается с формирования CSR (Certificate Signing Request- Запрос на Сертификат). Там указывается информация, которая в него будет внесена и одновременно формируется ключ сертификата, который должен храниться в тайне (именно этим ключом формируется электронная подпись).
После чего CSR передается в CA, формируется сертификат и PKCS#12 (если надо)
Так вот, Windows при формировании заявки так надежно сохраняет ключ, что достать его оттуда можно только путем нетривиальных действий.
Ну так вот - ты выпустил сертификат, наподписывал им кучу документов - а потом тачка возьми и сдохни. А бэкапа ключа у тебя нееет :) (юзерские тачки обычно не бэкапятся полностью)

Вот тебе и "только штатное решение" :)

[Дмитрий]

Да, я это понял, но цель данной задачи ускорить подписание внутренних документов, в которые вовлечено большое количество людей на распределённой территории и отказ от печати в бумагу. Ну и чтобы никто из пользователей не смог бы выпустить сертификат сам от другого сотрудника.
Если умрёт ПК, админ отзовёт тот потерянный и выпустит новый. Это плохо будет в практике?
Делаю по рекомендациям от Vadims Podans, автораздача идёт только шаблона Компьютер? Не понимаю как сделать именной для пользователя запрос и выдачу автоматом, такое возможно? Просто в ГПО для ПК есть раздел Automatic Certificate Request Setting, а в пользовательской нет

[Дмитрий]

Доброго времени суток, коллеги. Поднял СА, пока клиенты сами руками создают запрос и делают выпуск именного сертификата по шаблону Пользователь. Тут всё замечательно, кстати его можно экспортировать с закрытым ключом. Также всё хорошо и в самом бесплатном Adobe Reader, всё подписывается как надо. Проблема неожиданная прилетела со стороны проверки текущего сертификата пользователя на аннулирование (отзыв). По умолчанию в свойствах СА в закладке расширения ничего не меняя Adobe Reader ругался на ldap. Исходя из статьей:
https://www.sysadmins.lv/blog-en/designing-crl-dis...
и
https://learn.microsoft.com/ru-ru/windows-server/n...
сделал изменния. Ошибка теперь другая:

хотя пути прописаны при этом для точки распространения списков:
file://\\мойCA\CertEnroll\мойCA.crl
ttp://мойCA/certenroll/.crl
и для доступа к сведениям
http://мойCA/certenroll/_.crt
Причём что странно, можно оставить только первые записи c:\windows\system32.....
ошибка проверки будет та же.
Никто с этим не связывался?

[Дмитрий]

Коллеги! Вопрос закрыт, надо было всего лишь заново выпустить сертификат с изменёнными путями!)))

[CityCat4]

Дмитрий, Ну да, разумеется, CDP пишется в сертификат и его никак там не изменить :)