HTTPS до приватного IP: ідентичність сертифіката чи ім'я хоста?

Ваш сервіс за адресою https://10.60.0.25 може мати автентифікований TLS навіть без імені DNS. Адреса — це ідентичність, яку клієнт мусить перевірити, і сертифікат має описати її точно. Рішення в тому, чи ця адреса достатньо стабільна, щоб бути ідентичністю, чи ім'я хоста було б простіше підтримувати. VPN відповідає на доступність; на це він не відповідає.

Налаштуйте ідентичність і довіру правильно, і URL на основі IP буде законним рішенням.

Що клієнт насправді перевіряє

Клієнт порівнює еталонну ідентичність з URL з альтернативними іменами суб'єкта сертифіката. Для IP-адреси це означає запис iPAddress, що дорівнює адресі. Дружнє загальне ім'я не замінює його.

RFC 9525 відокремлює ідентичності IP-адрес від імен DNS і визначає правило збігу. Якщо вказати адресу лише в мітці суб'єкта або як запис типу DNS, збігу не буде. Тому саме SAN — те поле, яке треба перевірити, коли з'являється попередження.

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

Рішення перше: чи адреса достатньо стабільна, щоб бути ідентичністю

Якщо адреса фіксована на весь термін розгортання, сертифікат SAN IP простий і чесний. Якщо сервіс може переміщатися, кожне переміщення стає заміною сертифіката й узгодженим оновленням клієнтів.

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

Керований запис у файлі hosts може забезпечити зіставлення в малому середовищі. Він додає відповідальність за розповсюдження; він не замінює перевірку TLS.

Рішення друге: як клієнт довірятиме видавцю

Для приватного CA розповсюдьте якір довіри на призначені пристрої через схвалений механізм. Не привчайте користувачів проходити попередження або встановлювати сертифікат, який їм видає сторінка входу. Якщо ви хочете публічно довірений сертифікат, перевірте чинні правила видавця для приватних адрес, перш ніж планувати на них. Більшість публічних видавців не перевірятимуть приватний IP як публічну ідентичність.

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

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

Сплануйте зміну адреси до того, як вона станеться

Якщо 10.60.0.25 стане 10.60.0.40, старий сертифікат більше не описує URL. Сплануйте заміну й оновлення клієнта разом і ніколи не вимикайте перевірку під час переміщення.

Виберіть ідентичність, яку вводитимуть користувачі або налаштовуватимуть застосунки, а потім узгодьте навколо неї видачу, довіру, розгортання й оновлення. Доступна сторінка з відхиленим попередженням — не той самий результат, що сервіс, ідентичність якого клієнт перевіряє.