Zusammenfassung

  • TLS 1.3 certificate_authorities übermittelt geordnete, DER-codierte Distinguished Names. Sie lenken die Wahl einer Zertifikatskette, enthalten aber kein CA-Zertifikat, keinen vertrauenswürdigen Schlüssel, keinen validierten Pfad und keine Anwendungsberechtigung.
  • Im ClientHello beeinflusst die Liste die Serverzertifikatswahl; in CertificateRequest beeinflusst sie die Clientzertifikatswahl. Gleiches Datenformat bedeutet nicht gleiche Zuständigkeit.
  • Nachweisbare mTLS-Entscheidungen trennen Listenerzeugung, Credential-Auswahl, Pfadvalidierung und die Zuordnung der authentifizierten Identität zu einer erlaubten Aktion.

Der erfolgreiche Pfad, der nicht zum Zugriff führte

Ein Client besitzt mehrere Zertifikate. Die Bibliothek findet einen Issuer-DN in der Serverliste, wählt das passende Credential und beweist den Besitz des privaten Schlüssels. Der Server baut aus seiner aktuellen Konfiguration einen gültigen Pfad zu einem Trust Anchor.

Danach kann die Anwendung zu Recht ablehnen. Der SAN kann in einen anderen Namensraum zeigen, die Identität kann im falschen Mandanten liegen oder die geforderte Rolle fehlen. Pfadvalidierung authentifiziert ein Credential unter bestimmten Regeln. Sie entscheidet nicht, ob dieses Subjekt ein Secret lesen, eine Route ändern oder ein Artefakt signieren darf.

Ein Feld wie mtls_ca_allowed verdeckt diese Reihenfolge. Es sagt nicht, ob lediglich ein Name gesendet, ein Zertifikat gewählt, ein Anker akzeptiert oder eine Geschäftshandlung erlaubt wurde.

Der Name ist nicht der Vertrauensgegenstand

IANA führt certificate_authorities unter Erweiterungswert 47. RFC 9846 definiert einen nichtleeren Vektor DER-codierter X.501 Distinguished Names. Ein Name kann einen gewünschten Trust Anchor oder eine untergeordnete CA bezeichnen und soll die Auswahl des Gegenübers lenken.

Mit dem DN reisen weder öffentlicher Schlüssel noch Constraints, Richtlinien oder der Trust-Store-Eintrag. Zwei CA-Zertifikate können denselben Subject-Namen und verschiedene Schlüssel besitzen. Ein Parser kann außerdem den Subject eines Zertifikats extrahieren, das gar keine CA-Fähigkeit hat.

RFC-5280-Pfadvalidierung benötigt den konkreten Anchor und prüft Signaturen, Laufzeiten, Basic und Name Constraints, Key Usage sowie weitere Richtlinienwerte. Der Anchor kann in der übertragenen Kette fehlen, weil er unabhängig verteilt wird. Ein Name kann diese Prüfung nicht verkürzen.

Presence belegt nur, dass der Sender diesen codierten Namen in dieser Nachricht angekündigt hat. Es belegt nicht, dass jede darunter ausgestellte Kette akzeptiert wird. Omission belegt keine allgemeine Ablehnung; Listen können aus Datenschutz-, Größen- oder Auswahlgründen unvollständig sein.

Zwei Nachrichten, zwei Offenlegungen

Im ClientHello teilt der Client Informationen mit, die Serverzertifikat und alternative Serverkette beeinflussen. In CertificateRequest gibt der Server Hinweise für die Client-Credential-Auswahl. Erzeuger und Verbraucher wechseln die Seite.

OpenSSL weist darauf hin, dass clientseitige CA-Namen im Klartext zum Server gesendet werden. Ein automatischer Export des Unternehmens-Trust-Stores kann interne Organisationsbezeichnungen und PKI-Strukturen offenlegen. Umgekehrt erhöht eine übergroße Serverliste Handshake-Volumen und Auswahlaufwand.

Die alte Erweiterung trusted_ca_keys wird in TLS 1.3 nicht verwendet. Bei Mehrversionsangeboten können alte Signale vorkommen. Telemetrie muss daher Version, Nachricht, Richtung und Erweiterungstyp gemeinsam erfassen.

Auswahl bedeutet mehrere Filter zugleich

Neben dem CA-Namen wirken signature_algorithms, gegebenenfalls signature_algorithms_cert, Schlüsselart, vorhandener privater Schlüssel, Zertifikatssignatur, Key Usage, EKU, SNI, OID-Filter, Gültigkeit und lokal baubare Ketten.

Darum sind abgelehnte Kandidaten Beweismaterial. Ein Zertifikat kann namensgleich sein und an der EKU scheitern; ein anderes hat den passenden Schlüssel, aber keinen Pfad zur gewünschten CA. Nur den gewählten Leaf-Fingerprint zu speichern, erklärt die Entscheidung nicht.

Gibt es kein geeignetes Clientzertifikat, sendet TLS 1.3 eine leere Certificate-Nachricht. Der Server kann nach seinem Profil fortfahren oder certificate_required melden. Eine unpassende Identität als stiller Ersatz würde eine klare Protokollgrenze zerstören.

Ankündigungsliste und Verification Store laufen unabhängig

OpenSSL trennt APIs für gesendete CA-Namen von APIs für vertrauenswürdige Zertifikate. Das Setzen der Liste schafft kein Vertrauen; Verifikationsorte werden separat geladen.

Ein negativer Test macht das sichtbar: Kündigen Sie den Subject einer CA an, ohne deren Schlüssel als Anchor zu vertrauen. Der Client kann eine passende Kette auswählen, während der Server korrekt unknown_ca liefert. Umgekehrt kann eine lokal vertrauenswürdige Kette existieren, obwohl ihr Name nicht angekündigt wurde.

Hot Reload kann nur eine Seite ändern. Liste und Store brauchen daher eigene Generation, Hash, Aktivierungszeit und Zuordnung zu den Prozessen, die sie tatsächlich verwenden.

OpenSSL extrahiert beim Laden von Client-CA-Namen Subjects; die Eingabe ist nicht auf CA-Zertifikate beschränkt. Erfolgreiches Laden beweist Parsing, nicht CA-Autorität.

Nach der Authentifizierung beginnt die Autorisierung

Nach dem Pfad interpretieren Protokollregeln SANs und andere Identitätsmerkmale. Die Anwendung ordnet die normalisierte Identität einem Mandanten, Konto, Workload, einer Rolle und Aktion zu. Dafür können exakte SAN-Form, Issuer–Subject-Paar, Policy-OID, Enrollment oder ein externer Anspruch nötig sein.

Ein gültiges Zertifikat kann deshalb absichtlich abgelehnt werden. Auch der Client kann aus einem abgeschlossenen Handshake nicht sicher schließen, dass der Server ihn für die gewünschte Operation als gegenseitig authentifiziert betrachtet. Dazu kann ein explizites Anwendungsergebnis erforderlich sein.

OpenSSL, GnuTLS und BoringSSL stellen getrennte Auswahl- und Verifikationsflächen bereit. Ein installierter Callback zeigt Fähigkeit; erst eine verbindungsbezogene Invocation zeigt Ausführung. Einige BoringSSL-Werte gelten nur während des Auswahl-Callbacks und müssen dort kopiert oder gehasht werden.

Bei PSK-Resumption kann eine neue CertificateRequest im Haupthandshake ausbleiben. Ohne Zertifikatsaustausch darf Monitoring keine neue CA-Listen- oder Clientidentitätsentscheidung melden.

Negative Tests halten den Hinweis klein

Kündigen Sie einen DN ohne passenden vertrauenswürdigen Schlüssel an. Verwenden Sie zwei CAs mit gleichem Subject und vertrauen Sie nur einer. Bieten Sie ein namensgleiches Zertifikat mit falscher EKU, Laufzeit, Richtlinie oder fehlendem Schlüssel an und bewahren Sie den Ablehnungsgrund.

Lassen Sie den Pfad erfolgreich validieren und lehnen Sie anschließend am Mandanten ab. Entfernen Sie alle geeigneten Credentials und beobachten Sie leeres Certificate sowie Serverentscheidung. Ändern Sie Liste und Store getrennt und prüfen Sie, ob der Alarm die abweichende Generation nennt.

Messen Sie die Offenlegung im ClientHello, testen Sie große DN-Vektoren, zählen Sie bei Resumption keine neue Authentifizierung und unterscheiden Sie configured, invoked, selected, verified und authorized.

Die Beweiskette lautet: angekündigter Name, Kandidaten, gewähltes Credential, Schlüsselbesitz, validierter Pfad, interpretierte Identität, erlaubte Aktion. Keine Stufe darf die Autorität der nächsten übernehmen.

Quellen