Checkmate über TLS-Zertifikate in lokalen Netzwerken, selbstsignierte Zertifikate und CA

Question

Ich weiß kaum etwas über SSL- und TLS-Zertifikate. Das tut mir leid.

Das ist die Frage, die mein Unternehmen mir gestellt hat:

1. Sie müssen einen Server im lokalen Netzwerk platzieren, auf den Menschen im ganzen Land über VPN zugreifen können.
2. Sie möchten, dass dieser Server über HTTPS kommuniziert.
3. Sie möchten, dass der Server über ein TLS-Zertifikat verfügt, das von einer zertifizierten Zertifizierungsstelle erstellt wurde.
4. Sie sagen mir, dass der Server ein Microsoft IIS-Server ist.

Was ich bisher herausgefunden habe:

1. Es ist beispielsweise nicht möglich, von einer zertifizierten Zertifizierungsstelle ein SSL-Zertifikat für einen Intranet-Server erstellen zu lassen, dessen Adresse server.mydomain.localnicht über das Internet erreichbar ist.
2. Die einzige Möglichkeit, ein SSL-Zertifikat für diesen Server zu erhalten, ist ein selbstsigniertes Zertifikat, aber diese Zertifikate gelten nicht gerade als vertrauenswürdig für Dinge wie iOS usw. iOS hasst selbstsignierte Zertifikate und deren Inhalt sind im Grunde iOS-Geräte, die auf einen lokalen Server zugreifen.

Ich brauche eine Bestätigung, dass ich Recht habe, und wenn nicht, eine Möglichkeit, dieses Schachmatt zu lösen.

Danke

Answer 1

Sie haben Recht, dass öffentliche Zertifizierungsstellen nur Zertifikate für öffentliche Domänennamen ausstellen (da sie diese überprüfen können). Sie übersehen jedoch, dass dies nicht unbedingt etwas damit zu tun hat, ob der Server öffentlich zugänglich ist oder nicht, und auch nicht damit, ob er eine öffentliche IP-Adresse hat oder nicht.Der Server muss nichtSeiöffentlich, um einen öffentlichen Domänennamen zu haben.

Die Zertifizierungsstelle befasst sich lediglich mit der Überprüfung des Eigentums an dem Namen, der in der URL enthalten sein wird.MancheCAs wie Let's Encrypt stellen dazu normalerweise eine Verbindung zum Server über HTTP her (obwohl das nicht mehr die einzige Option ist). Viele andere CAs ermöglichen es Ihnen jedoch, nur den Besitz der gesamten Domain zu überprüfen (möglicherweise über Whois-Einträge) und stellen dann kostenlos Zertifikate für jede Subdomain aus, sogar für Subdomains, die keinen Webserver haben, oder solche, die nichts öffentlich Zugängliches haben, oder sogar für Subdomains, die überhaupt nicht existieren.

Ich gehe also davon aus, dass das Unternehmen bereits eine Website und damit einen öffentlichen Domänennamen hat. Je nachdem, womit das Unternehmen einverstanden ist, gibt es mehrere Möglichkeiten, wie Sie vorgehen können:

• Sie könnten den Server eine normale öffentliche IP-Adresse verwenden lassen und sie wie immer in DNS eintragen ... und den Server einfach alle Verbindungen ablehnen lassen, die nicht über das VPN hergestellt werden, zum Beispiel mithilfe der Windows-Firewall oder einiger IIS-spezifischer Einstellungen.

  (Die meisten VPN-Systeme können so konfiguriert werden, dass jeder beliebige IP-Adressbereich durch den sicheren Tunnel geleitet wird. Dabei spielt es keine Rolle, ob die IP-Adressen „öffentlich“ oder „privat“ sind. Es ist ganz normal, den öffentlichen IP-Bereich des Unternehmens durch das Firmen-VPN zu leiten.)

• Sie können eine Subdomäne erstellen, die auf eine interne IP-Adresse verweist – beispielsweise server.corp.mydomain.comeine öffentliche Subdomäne, die auf 192.168.7.1 verweist, eine private IP-Adresse, die nur über ein VPN zugänglich ist – und das verhindert trotzdem nicht, dass ein öffentlich gültiges HTTPS-Zertifikat ausgestellt wird.

  (Hierfür ist hinsichtlich der DNS-Einrichtung nichts Besonderes erforderlich, Sie können eine Domäne buchstäblich einfach auf jede beliebige Adresse verweisen lassen.)

• Sie könnten den eigentlichen Webserver unter einer privaten IP-Adresse haben, aber einen „Reverse-Proxy“-Frontend-Server unter einer öffentlichen IP-Adresse verwenden. Der Reverse-Proxy könnte sowohl IP-basierten Zugriff als auch SSO oder Kennwortauthentifizierung handhaben. Er könnte sogar die HTTP-basierte Zertifikatsausgabe von Let’s Encrypt im Namen des echten privaten Servers handhaben.

  (Wir verwenden diese Methode, um einigen alten, verrosteten Webanwendungen einen sicheren HTTPS-Zugriff zu ermöglichen – eine davon läuft noch auf Server 2003 und kann mit modernen Browsern überhaupt nicht umgehen, stattdessen bietet der Reverse-Proxy die notwendige TLS 1.2-Unterstützung sowie SAML-Authentifizierung.)

(Es gibt auch andere Optionen. Zusätzlich zu öffentlichen CAs kann jeder seine eigene CA erstellen und die meisten Unternehmensnetzwerke, auf denen Microsoft AD läuft, haben tatsächlich eine – das einzige Problem besteht darin, die Geräte dazu zu bringen, dieser CA zu vertrauen, aber für iPhones, die von Unternehmen ausgegeben werden, sollte das über das „Mobile Device Management“-System, das das Unternehmen verwendet, einfach zu bewerkstelligen sein. Aber sagen Sie den Leuten nicht, dass sie eine Unternehmens-CA auf privaten Systemen installieren sollen …)