HTTPS auf eine lokale IP: Zertifikatsidentität oder Hostname?
Eine lokale IP kann eine gültige TLS-Identität sein, wenn das Zertifikat es vorsieht. Wählen Sie zwischen einem IP-SAN und einem stabilen Hostname und planen Sie dann den Adresswechsel.
Ihr Dienst unter https://10.60.0.25 kann authentifiziertes TLS haben, auch ohne DNS-Namen. Die Adresse ist die Identität, die der Client prüfen muss, und das Zertifikat muss sie exakt beschreiben. Die Entscheidung ist, ob diese Adresse stabil genug für eine Identität ist oder ob ein Hostname leichter zu pflegen wäre. Das VPN beantwortet die Erreichbarkeit; es beantwortet dies nicht.
Stimmen Identität und Vertrauen, ist eine IP-basierte URL ein legitimes Design.
Was der Client tatsächlich prüft
Der Client vergleicht die Referenzidentität in der URL mit den alternativen Namen des Zertifikats. Bei einer IP-Adresse bedeutet das einen iPAddress-Eintrag, der der Adresse entspricht. Ein freundlicher allgemeiner Name ist kein Ersatz.
RFC 9525 trennt IP-Adressidentitäten von DNS-Namen und definiert die Abgleichsregel. Wird die Adresse nur im Subjektfeld oder als Eintrag vom Typ DNS angegeben, entsteht kein Treffer. Deshalb ist das SAN das Feld, das bei einer Warnung zu prüfen ist.
Vertrauen ist eine zweite, unabhängige Prüfung. Ein Namensabgleich behebt keine nicht vertrauenswürdige Kette, kein abgelaufenes Zertifikat und kein für einen anderen Zweck ausgestelltes Zertifikat.
Entscheidung eins: Ist die Adresse stabil genug für eine Identität
Ist die Adresse für die gesamte Lebensdauer des Einsatzes fest, ist ein IP-SAN-Zertifikat einfach und ehrlich. Kann der Dienst umziehen, wird jeder Umzug zu einem Zertifikatsersatz und einer abgestimmten Client-Aktualisierung.
Ein stabiler Hostname verringert diese Kopplung. Clients nutzen den Namen, das freigegebene DNS ordnet ihn der aktuellen Adresse zu, und ein Adresswechsel ist keine Identitätsänderung mehr. Das Zertifikat muss weiterhin erneuert werden, die URL ändert sich aber nicht.
Ein verwalteter hosts-Dateieintrag kann die Zuordnung in einer kleinen Umgebung liefern. Er fügt eine Verteilungsverantwortung hinzu; er ersetzt die TLS-Prüfung nicht.
Entscheidung zwei: Wie der Client dem Aussteller vertraut
Bei einer privaten CA verteilen Sie das Vertrauensanker über einen freigegebenen Mechanismus an die vorgesehenen Geräte. Bringen Sie Nutzern nicht bei, Warnungen wegzuklicken oder ein Zertifikat zu installieren, das ihnen eine Anmeldeseite übergibt. Wenn Sie ein öffentlich vertrauenswürdiges Zertifikat möchten, prüfen Sie die aktuellen Regeln des Ausstellers für private Adressen, bevor Sie damit planen. Die meisten öffentlichen Aussteller validieren eine private IP nicht als öffentliche Identität.
Prüfen Sie den tatsächlichen Browser oder die Anwendung. Deren Vertrauensspeicher und Validierungsverhalten sind wichtiger als die allgemeine Zertifikatsdokumentation des Betriebssystems. Prüfen Sie es auf dem tatsächlichen Gerät, nicht nur in der Konsole.
Das VPN-Gateway ist möglicherweise nicht die Maschine, die die Webanwendung ausführt, gehen Sie also nicht davon aus, dass das Zertifikat des Tunnels etwas damit zu tun hat.
Planen Sie den Adresswechsel, bevor er eintritt
Wird aus 10.60.0.25 die Adresse 10.60.0.40, beschreibt das alte Zertifikat die URL nicht mehr. Planen Sie Ersatz und Client-Aktualisierung gemeinsam und deaktivieren Sie die Prüfung während des Umzugs niemals.
Wählen Sie die Identität, die Nutzer eingeben oder Anwendungen konfigurieren werden, und richten Sie Ausstellung, Vertrauen, Einsatz und Erneuerung daran aus. Eine erreichbare Seite mit weggeklickter Warnung ist nicht dasselbe Ergebnis wie ein Dienst, dessen Identität der Client prüft.