Невидимые ключи доверия и как навести в них порядок на рабочей машине

Сертификаты живут в Windows тихой жизнью, о которой большинство пользователей не подозревает. Они работают за кулисами, когда человек заходит на защищённый сайт, подписывает документ электронной подписью или подключается к корпоративному ресурсу. Всё идёт гладко ровно до того дня, пока что-то не ломается: браузер вдруг ругается на недоверенное соединение, программа отказывается запускаться из-за просроченной подписи, а система электронного документооборота не видит нужного ключа. И тогда выясняется, что за внешней простотой скрывается целое хозяйство, которым кто-то должен управлять.

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

Личное хранилище и хранилище компьютера как две разные вселенные

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

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

Внутри каждого уровня сертификаты ещё и разложены по логическим хранилищам с говорящими именами. Личное хранилище держит сертификаты самого владельца, обычно вместе с закрытыми ключами. Доверенные корневые центры сертификации содержат корневые сертификаты тех центров, чьим подписям система верит безоговорочно. Доверенные лица хранят сертификаты конкретных людей и сервисов, которым выдано отдельное доверие. Эта структура повторяется и на уровне пользователя, и на уровне компьютера, образуя стройную, хотя поначалу и запутанную систему полок.

Графический диспетчер как точка входа для разовых задач

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

certmgr.msc

Эта оснастка показывает всё пользовательское хозяйство в наглядном виде: слева дерево логических хранилищ, справа сами сертификаты с их сроками действия и назначением. Через неё импортируют новый сертификат, выбрав нужную полку и указав путь к файлу, экспортируют существующий в файл или удаляют отживший. Для разовой задачи на одной машине этого вполне достаточно, и многим администраторам дальше графической оснастки погружаться не приходится.

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

certlm.msc

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

Командная установка сертификатов через certutil

Графика хороша для штучной работы, но при разворачивании сертификатов на парке машин нужна командная строка. Главный инструмент здесь это утилита certutil, входящая в состав Windows уже много лет. Она позволяет добавлять сертификаты в нужные хранилища скриптом, что бесценно при массовой настройке. Установка сертификата в личное хранилище текущего пользователя выглядит так:

certutil -user -addstore "My" "C:\Certs\Сертификат.cer"

Здесь ключ пользователя указывает уровень, параметр добавления в хранилище с именем личного хранилища задаёт полку, а дальше идёт путь к файлу. Имена логических хранилищ в этой утилите служебные и не совпадают с теми, что видны в графике: личное зовётся коротким техническим именем, доверенные корневые центры обозначаются по-своему, доверенные лица тоже имеют своё кодовое имя. Установка корневого сертификата в хранилище доверенных центров отличается лишь именем полки:

certutil -addstore "Root" "C:\Certs\КорневойСертификат.cer"

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

Просмотр и проверка установленных сертификатов из консоли

Прежде чем что-то ставить или удалять, полезно увидеть, что уже есть в хранилище. Та же certutil умеет выводить содержимое полки, и просмотр личного хранилища пользователя выполняется командой со словом хранилища без добавления:

certutil -user -store "My"

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

PowerShell предлагает ещё более удобный способ обзора через виртуальный диск сертификатов, по которому можно ходить как по обычным папкам. Хранилища представлены путями, и перечисление личного хранилища пользователя выглядит наглядно:

Get-ChildItem Cert:\CurrentUser\My

Этот подход особенно хорош для скриптов, потому что возвращает сертификаты как объекты, которые легко фильтровать по сроку действия, отпечатку или назначению. Можно за одну команду найти все сертификаты, что истекают в ближайший месяц, и заранее заняться их обновлением, не дожидаясь, пока что-нибудь сломается. Объектный подход PowerShell превращает рутинный аудит сертификатов из утомительного перебора в короткий запрос.

Типичные сценарии, в которых порядок в сертификатах решает всё

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

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

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

Экспорт сертификата и тонкая грань вокруг закрытого ключа

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

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

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

Удаление отживших сертификатов и поддержание чистоты хранилища

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

Удаление через графическую оснастку сводится к выбору ненужного сертификата и команде удаления, но при массовой работе снова выручает certutil с возможностью убрать сертификат из хранилища по его идентификатору. Перед удалением разумно лишний раз свериться по выводу содержимого полки, чтобы под нож не попал нужный сертификат, особенно если несколько записей похожи по имени владельца. Здесь действует то же правило осторожности, что и при чистке сохранённых паролей: сначала посмотреть глазами, потом удалять.

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

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