Сертифікат для сайту лише через VPN: DNS-01 чи приватний CA?

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

Сертифікат доводить ім’я; VPN і внутрішній DNS забезпечують шлях.

Два шляхи до довіреного імені

Публічний видавець із перевіркою DNS-01 доводить контроль над іменем через запис TXT у зоні, якою ви керуєте, тож вебслужбі ніколи не доводиться приймати публічне HTTP-з’єднання. Приватний CA видає кінцеві сертифікати для внутрішніх імен і поширює свій якір довіри через керування пристроями, тож жоден публічний журнал не дізнається імені. Обидва варіанти законні, і вибір випливає з тих трьох умов, а не зі зручності. Жоден зі шляхів не дає маршрут або запис резолвера, потрібний клієнту.

Публічний сертифікат також публікує ім’я хоста в журналах прозорості сертифікатів. Якщо саме ім’я чутливе, це розкриття є проєктним рішенням, а не побічним ефектом, який виявиться пізніше.

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

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

Чекайте на поширення з перевіркою проти авторитетних серверів, а не з фіксованою паузою. Поведінка поширення залежить від постачальника, і пауза, що працює сьогодні, не є доказом на завтра.

Керовані клієнти та навмисно приватні імена

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

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

Поновлення — частина проєкту

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

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

Запишіть видавця, метод перевірки, канал поширення довіри та механізм перезавантаження. Ці чотири пункти і є план поновлення.