AWS Client VPN: Serverzertifikat und die Rolle des Clientzertifikats
Das Serverzertifikat des Endpunkts weist den Dienst aus. Gegenseitige Authentifizierung ergänzt Identitäten je Client und CA-Vertrauen, ohne den Serverschlüssel zu teilen.
Ein Client-VPN-Endpunkt benötigt immer ein TLS-Serverzertifikat. Das ist die Identität, die der verwaltete Endpunkt vorzeigt, wenn sich ein Client verbindet. Es ist ein anderes Objekt als die Zertifikate, die einzelne Clients bei gegenseitiger Authentifizierung vorzeigen. Diese beiden zu verwechseln ist der häufigste Grund, warum eine ansonsten korrekte ACM-Einrichtung bei der ersten Verbindung scheitert.
Hier ist ein Durchgang von der Konsole nach außen, in der Reihenfolge, die eine Verbindung tatsächlich durchläuft.
Zwei Rollen, ein Endpunkt
Der Endpunkt besitzt eine Serveridentität und optional eine Möglichkeit, Clientidentitäten zu prüfen. Beides wird getrennt konfiguriert. Das eine entscheidet, ob der Client dem Dienst vertrauen kann; das andere entscheidet, ob der Dienst den Client akzeptiert.
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
Lesen Sie die Tabelle als drei unabhängige Anforderungen statt als ein Zertifikat. Das Serverzertifikat und sein privater Schlüssel bleiben beim Dienst. Ein Clientzertifikat und der passende private Schlüssel liegen auf dem Gerät. Das CA-Material ist das, womit eine prüfende Stelle die Kette kontrolliert. Nur die mittlere Zeile gehört jemals auf einen Laptop.
Was das ACM-Serverzertifikat leistet
Beim Erstellen des Endpunkts muss das Serverzertifikat in ACM in derselben Region wie der Endpunkt verfügbar sein. Die Konsole fragt nach einem ARN, und dieser ARN muss dort auflösbar sein. ACM kann ein Zertifikat halten, das Sie mit Domänenvalidierung bereitgestellt haben, oder eines, das Sie zusammen mit Schlüssel und Kette importiert haben. Beide funktionieren in dieser Rolle; sie unterscheiden sich bei der Erneuerung und darin, wer den privaten Schlüssel hält.
Wählen Sie den Bereitstellungsweg danach, wer das Zertifikat erneuern kann, nicht danach, welcher zufällig eine gültig aussehende Datei erzeugt hat.
Was gegenseitige Authentifizierung ergänzt
Die Auswahl zertifikatsbasierter Clientauthentifizierung fügt eine zweite Frage hinzu: welche Clients überhaupt verbinden dürfen. Jeder Client zeigt sein eigenes Zertifikat vor und weist den Besitz des passenden privaten Schlüssels nach. Getrennte Identitäten ermöglichen später den gezielten Widerruf. Einen Client-Schlüssel auf jedes Gerät zu kopieren verwirft diese Eigenschaft stillschweigend, selbst wenn das Serverzertifikat einwandfrei beschafft wurde.
Die Authentifizierungsmethode des Endpunkts ist eine Wahl, keine allgemeine Anforderung.
Active Directory und föderierte Authentifizierung beantworten dieselbe Frage mit anderen Mitteln. Ein Rezept mit gegenseitigen Zertifikaten ist nicht automatisch das Anmeldedesign für solche Bereitstellungen, und die TLS-Prüfung des Servers bleibt bestehen, unabhängig davon, wie der Benutzer eingelassen wird.
Warum derselbe CA-ARN keine Schlüsselweitergabe ist
AWS dokumentiert, dass bei von derselben CA ausgestellten Server- und Clientzertifikaten der ARN des Serverzertifikats auch für die Auswahl des Clientzertifikats verwendet werden kann. Dieser Satz betrifft die Kette, der der Endpunkt bei der Prüfung vertraut. Er sagt Clients nicht, den privaten Schlüssel des Servers zu verwenden. Ein Laptop braucht weiterhin sein eigenes Clientzertifikat und seinen eigenen passenden Schlüssel.
Wenn die Client-CA ein anderer Aussteller ist, besteht der dokumentierte Weg darin, diese CA in ACM zu importieren und sie für die Clientrolle auszuwählen.
Den Fehler auf eine Stufe zurückführen
Bestimmen Sie, welche Stufe fehlschlägt, bevor Sie etwas austauschen. Wenn der Client den Endpunkt ablehnt, sind der Server-ARN oder seine Kette verdächtig. Wenn der Endpunkt den Client ablehnt, prüfen Sie das Clientzertifikat, seinen Aussteller und die gewählte Authentifizierungsmethode. Wenn der Tunnel steht und der Datenverkehr weiterhin scheitert, sind Sie über die Zertifikate hinaus.
Tauschen Sie jeweils ein Objekt aus, denn beide Enden gleichzeitig zu wechseln reproduziert die Mehrdeutigkeit, mit der Sie begonnen haben.
Prüfen Sie außerdem die unterstützten Schlüsselalgorithmen und erforderlichen Erweiterungen des Dienstes für die jeweilige Rolle. Ein Zertifikat, das einer öffentlichen Website genügt, ist kein Beweis dafür, dass alle Identitätsanforderungen für Client VPN erfüllt sind.
Notieren Sie, welcher ARN in welchem Feld steht, welche CA das Clientzertifikat ausgestellt hat und welche Authentifizierungsmethode der Endpunkt tatsächlich nutzt. Drei Zeilen Aufzeichnung machen die nächste Erneuerung zu einer Aufgabe statt zu einer Untersuchung.