Почему копирование ca.key на каждый VPN-клиент ломает CA

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

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

Материал проверки и материал подписи

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

Поэтому ca.crt принадлежит профилю, а ca.key не принадлежит нигде поблизости. Имена файлов — условность, а не гарантия, поэтому тип нужно проверять, а не выводить из имени.

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

Что клиент должен доказать своим собственным ключом

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

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

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

Прочитайте файл, прежде чем куда-либо его копировать

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

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Если вторая команда успешно выполнится на файле, лежащем в клиентском наборе, остановитесь и считайте набор скомпрометированным. Вывод о том, что ключ действителен, означает также, что он присутствует, и само присутствие — вся проблема.

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

Сдерживание уже распространённого ключа

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

Затем измените упаковку, которая создала проблему. Отправляйте список каталога с явным перечнем разрешённых файлов, держите ключ CA на машине, которая никогда не входит в парк клиентов, и записывайте, какая система его хранит.

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