HTTPS к частному IP: идентичность сертификата или имя хоста?
Частный IP может быть действительной идентичностью TLS, если сертификат это указывает. Выберите между SAN 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. Спланируйте замену и обновление клиента вместе и никогда не отключайте проверку во время переезда.
Выберите идентичность, которую будут вводить пользователи или настраивать приложения, затем согласуйте вокруг неё выдачу, доверие, развёртывание и обновление. Доступная страница с отклонённым предупреждением — не тот же результат, что сервис, идентичность которого проверяет клиент.