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

Сертификат подтверждает имя; VPN и внутренний DNS обеспечивают путь.

Два пути к доверенному имени

Публичный издатель с проверкой DNS-01 подтверждает контроль над именем через запись TXT в зоне, которой вы управляете, поэтому веб-службе никогда не приходится принимать публичное HTTP-соединение. Частный CA выпускает конечные сертификаты для внутренних имён и распространяет свой якорь доверия через управление устройствами, поэтому ни один публичный журнал не узнаёт имя. Оба варианта законны, и выбор следует из этих трёх условий, а не из удобства. Ни один из путей не даёт маршрут или запись резолвера, которая нужна клиенту.

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

DNS-01 без раскрытия службы

Запись проверки — это запись TXT под зарезервированным префиксом в зоне, и издатель читает её из авторитетного DNS. Выберите клиент ACME и интеграцию с DNS, которые умеют создавать и удалять эту запись, и выдавайте разрешение на обновление узко: ограниченные учётные данные API для зоны или контролируемый хост, используемый только для проверки. Давать серверу приложения неограниченные учётные данные регистратора ради продления одного сертификата — это гораздо больше прав, чем нужно задаче. Когда несколько заказов делят одно имя, держите их значения TXT раздельно, чтобы очистка одного не удалила значение, которое всё ещё нужно другому.

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

Управляемые клиенты и намеренно частные имена

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

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

Продление — часть проекта

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

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

Запишите издателя, метод проверки, канал распространения доверия и механизм перезагрузки. Эти четыре пункта и есть план продления.

Похожие статьи