Alternative Antragstellernamen: Wie ein VPN-Server identifiziert wird

Ihr Client lehnt ein Zertifikat ab, dessen Kette sauber validiert, und der Fehler meldet, dass der Name nicht passt. Diese Meldung betrifft nicht, wer das Zertifikat signiert hat. Sie betrifft die Erweiterung für alternative Antragstellernamen, die die Identitäten trägt, welche das Zertifikat vertreten darf, und ob die von Ihnen konfigurierte Identität dort in der richtigen Form erscheint. Vertrauen beantwortet, wer es signiert hat, während die Namensprüfung beantwortet, zu welchem Host es gehört.

Was der Client tatsächlich vergleicht

Der Client wandelt Ihre Konfiguration in eine Referenzidentität um: einen Hostnamen, eine Adresse oder eine protokollspezifische Kennung. Dann sucht er im Zertifikat nach dieser Identität und wendet die Abgleichregeln des verwendeten Protokolls an. Nur Einträge desselben Typs zählen, daher kann ein DNS-Eintrag keine Adresse erfüllen, und der Vergleich findet statt, ob ein Mensch jemals das Zertifikat ansieht oder nicht.

Fehlt die Referenzidentität in dieser Erweiterung, schlägt die Prüfung fehl, selbst wenn der alte allgemeine Name passt. Ein Zertifikat kann rechtmäßig für ein Unternehmen ausgestellt sein und trotzdem das falsche für vpn.example.com sein, wenn der Name nie aufgenommen wurde. Der Fehlschlag ist eine Namensabweichung, obwohl das Zertifikat echt ist.

DNS-Namen und IP-Adressen sind getrennte Einträge

Ein Profil, das auf 203.0.113.10 zeigt, während das Zertifikat nur vpn.example.com auflistet, wird abgelehnt, weil die Pakete ankommen, die Identität aber nicht passt. DNS-Namen und Adressliterale werden als unterschiedliche Eintragstypen gespeichert, und das eine ersetzt nie das andere. Deshalb kann ein Dienst über die Adresse erreichbar und trotzdem über ein Profil unbrauchbar sein, das diese Adresse verwendet.

Platzhalter folgen ebenfalls eigenen Regeln: Ein Platzhalter deckt ein einzelnes Label ab, nicht jeden Namen unter einer Domain. Der DNS-Vergleich ist nicht groß- und kleinschreibungssensitiv, andere Kennungstypen sind es, sodass ein auf dem Bildschirm identisch wirkender Wert einen strengen Vergleich scheitern kann. Prüfen Sie die Abgleichregeln für den verwendeten Identitätstyp, statt Zeichenketten mit dem Auge zu vergleichen. Einen Namen zur Erweiterung hinzuzufügen ist außerdem eine Ausstellungsentscheidung und nichts, was eine Client-Einstellung liefern kann.

Prüfen Sie das Zertifikat, das die Verbindung wirklich verwendet hat

Lesen Sie das Material, das der aktive Endpunkt präsentiert, nicht eine von einer Verwaltungsseite kopierte Datei. Ein Lastverteiler oder eine Ersatzinstanz kann etwas anderes präsentieren als das vor Monaten hochgeladene Zertifikat, und dieser Unterschied ist in einer Konsole unsichtbar.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

Der Block der alternativen Antragstellernamen, die Ausstellerkette und die Gültigkeitsdauer gehören in denselben Lesevorgang, weil eine Namensabweichung und ein Ablauf unterschiedliche Fehler erzeugen. Vergleichen Sie jeden Namen in diesem Block Zeichen für Zeichen mit der im Profil konfigurierten Identität und notieren Sie, welcher Typ es ist. Wiederholen Sie den Befehl gegen die Adressform des Endpunkts, zeigt sich, ob das Zertifikat beide Identitäten oder nur eine abdeckt. Eine freundliche Betreffanzeige in einer Verwaltungskonsole ist kein Validierungsergebnis und sagt nichts darüber, welche Namen die Erweiterung enthält.

Der allgemeine Name ist nicht die moderne Quelle der Wahrheit

Browser und die meisten TLS-Bibliotheken ignorieren den allgemeinen Namen inzwischen für den Hostnamenabgleich und konsultieren stattdessen die Erweiterung. Manche VPN-Clients vergleichen weiterhin zuerst den allgemeinen Namen oder weichen darauf zurück, wenn die Erweiterung fehlt, und so kann ein Zertifikat in einem Browser bestehen und in einem Client scheitern. Dieselbe Namensprüfung kann auf einer Plattform bestehen und auf einer anderen scheitern, ohne dass sich das Zertifikat überhaupt ändert.

Finden Sie heraus, welches Feld Ihr Client liest, bevor Sie entscheiden, dass das Zertifikat falsch ist. Zwei Clients am selben Endpunkt können sich widersprechen, und der Widerspruch ist eine Information über den Client, nicht über das Zertifikat.

Reparieren Sie die Ausstellung oder das Profil, nicht die Prüfung

Wurde ein Profil um einen Alias herum gebaut, richten Sie es entweder auf den dokumentierten Hostnamen oder stellen Sie das Zertifikat für den Alias erneut aus und bringen es in einem geplanten Fenster aus. Die Warnung stumm zu schalten ist keine dritte Option, weil die Prüfung der einzige Schritt ist, der ein signiertes Zertifikat an diesen bestimmten Host bindet. Sie zu entfernen bedeutet, dass jedes Zertifikat derselben Behörde für den Server einspringen kann, den Sie erreichen wollten.

Eine Erneuerung sollte die vorgesehenen Namen und den Zweck bewahren, statt nur das Ablaufdatum nach vorn zu schieben. Eine Erneuerung, die einen Namen fallen lässt, ist ein neuer Ausfall, der für den nächsten Neustart geplant ist, und er kommt meist ohne Vorwarnung, weil das alte Zertifikat noch gültig war, als die Änderung erfolgte.

Halten Sie die erwartete Identität, die präsentierten Namen und die Kette fest, die sie signiert hat. Diese Aufzeichnung macht die nächste Erneuerung zu einem Vergleich statt zu einer Untersuchung. Die Definition der Erweiterung steht in RFC 5280, wenn Sie eine bestimmte Ausstellung prüfen müssen.