Welche PKCS#11-URI braucht OpenConnect für ein Token?

Eine Smartcard, die den richtigen Schlüssel bereits enthält, muss trotzdem erfahren, welches Objekt darauf verwendet werden soll. OpenConnect will in dieser Lage keine kopierte .key-Datei; es will eine PKCS#11-URI, die das Zertifikat benennt und, wenn die automatische Suche die Aufgabe nicht abschließen kann, den privaten Schlüssel daneben. Das Unangenehme daran ist, dass eine syntaktisch gültige URI nichts beweist. Sie muss die Registrierung benennen, der das Gateway bereits vertraut, nicht bloß ein Objekt, das die Karte zu öffnen bereit ist.

Was der Client statt eines exportierten Schlüssels will

Die Option -c nimmt normalerweise einen Dateipfad, aber wenn der Wert als PKCS#11-URI geparst wird, behandelt OpenConnect ihn als Verweis auf ein Objekt im Token statt auf eine Datei auf der Platte. Die Option -k verhält sich für den privaten Schlüssel genauso. Nichts wird exportiert, und der Schlüssel verlässt nie den Schutz, den die Karte bietet. Was der Client von Ihnen braucht, ist ein Name, auf den sich Tokenmodul, Zertifikatsspeicher und Gateway-Registrierung einigen.

An der letzten Bedingung scheitern die meisten Versuche. Eine URI kann vollkommen wohlgeformt sein und trotzdem ein Zertifikat auswählen, das das Gateway ablehnt, denn Gültigkeit und Relevanz sind getrennte Fragen. Die Prüfung, die sich lohnt, ist ein Vergleich mit dem Registrierungsdatensatz, nicht die Suche nach dem ersten Objekt, das sich zufällig öffnet.

Zwei URIs, zwei verschiedene Aufgaben

Die Zertifikats-URI beantwortet, welche Identität Sie beanspruchen. Sie zeigt auf ein Zertifikatsobjekt, dessen öffentlicher Schlüssel und Betreffzeile zum Konto- oder Geräteprofil passen, das der VPN-Administrator ausgestellt hat. Dasselbe Zertifikat kommt meist mit einem daneben gespeicherten Objekt für den privaten Schlüssel, und genau dieses Paar braucht der TLS-Handshake.

Die Schlüssel-URI beantwortet, wo das passende private Material liegt, wenn OpenConnect es nicht ableiten kann. Mit nur gesetztem -c baut der Client eine Schlüsselsuche aus den Zertifikatseigenschaften; die Angabe von -k ersetzt die Vermutung durch einen ausdrücklichen Objektverweis. Die PIN des Tokens ist eine dritte, unabhängige Eingabe: Sie schaltet die Karte für den Vorgang frei und benennt nie ein Objekt.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Alles in dieser Zeichenkette in Anführungszeichen sind Daten. Die Semikolons trennen URI-Attribute, und die Prozent-Escapes kodieren Zeichen, die sonst die Auswertung brechen würden, deshalb muss das ganze Argument die Shell unversehrt überstehen.

Die URI finden, die zu Ihrer Registrierung passt

GnuTLS liefert p11tool mit, das auflistet, was der aktuelle Benutzer über p11-kit tatsächlich erreichen kann. Beginnen Sie mit p11tool --list-tokens und listen Sie dann die Zertifikatsobjekte auf dem Token, der Sie interessiert. Fügen Sie --login hinzu, wenn die Objekte erst nach einer PIN erscheinen, und vergleichen Sie Betreff und Aussteller mit dem Registrierungsdatensatz, statt das Erstbeste zu nehmen.

Wenn das Token gar nicht auftaucht, liegt das Problem unterhalb von OpenConnect: p11-kit hat kein Modul für diese Middleware registriert, oder das Modul ist für ein anderes Konto registriert. Die systemweite Registrierung liegt unter /etc/pkcs11/modules, und ein benutzerspezifisches Verzeichnis kann dasselbe enthalten, ohne die Systemkopie anzufassen. Prüfen Sie, ob der Anbieterpfad in der Moduldatei auf eine Bibliothek zeigt, die die Software des Lesers tatsächlich installiert hat.

Wenn Sie die URI aus der Auflistung kopieren, behalten Sie die Anführungszeichen darum. Unquotierte Semikolons schneiden das Argument beim ersten Attribut ab, und der Client meldet dann ein Objekt, das er nicht finden kann.

Wenn die automatische Schlüsselsuche aufgibt

OpenConnect kann aus der Zertifikats-URI eine Schlüsselsuche ableiten, aber die genaue Zuordnung, die es vornimmt, hängt von der Version ab, und der Umgang mit Objekttyp und Label hat sich mit der Zeit geändert. Der Rat, die URI zu kürzen, bis sie funktioniert, beschreibt einen alten Behelf, keine Anforderung. Wenn die abgeleitete Suche scheitert, benennen Sie den Schlüssel ausdrücklich mit -k, statt die Zertifikats-URI zu etwas Unschärferem umzubauen.

Bestätigen Sie mit p11tool --list-keys, dass der Schlüssel existiert und sichtbar ist, bevor Sie den Client beschuldigen. Prüfen Sie dann, ob das Objekt als nutzbar für Signatur oder Entschlüsselung markiert ist, denn ein mit falschen Attributen erzeugter Schlüssel kann keinen Handshake abschließen, so korrekt die URI auch ist. Übertragen Sie keinen serialisierten pkcs11-id-Wert aus einem OpenVPN-Profil in eine OpenConnect-Option; die beiden Clients verwenden unterschiedliche Kennungsformate, selbst wenn sie mit derselben Karte sprechen.

Wenn die URI aufgelöst und die PIN akzeptiert wird, die Authentifizierung aber trotzdem scheitert, hören Sie auf, an der URI zu drehen. Lesen Sie den Fehler des Gateways selbst, denn der nächste Fehler liegt oberhalb des Tokens.

Fehler, die nur wie URI-Probleme aussehen

Ein Gateway, das ein anderes Protokoll spricht, scheitert identisch, ob Ihre URI richtig oder falsch ist. OpenConnect hat den alten vpnc-Client aus gutem Grund ersetzt, und Kartenunterstützung macht ein inkompatibles Gateway-Protokoll nicht kompatibel. Bestätigen Sie das erwartete Protokoll des Servers und die Authentifizierungsanordnung, bevor Sie eine weitere Stunde in Objektattribute stecken.

Auch die Prüfung der Serveridentität ist eine eigene Schicht. Der Client verifiziert das Gateway-Zertifikat gegen seinen Vertrauensspeicher, und diese Prüfung läuft, nachdem die Karte ihren Teil bereits erledigt hat. Leserberechtigungen und ein gestoppter pcscd-Dienst erzeugen dasselbe äußere Symptom, ein unlesbares Token, bei einer viel einfacheren Behebung.

Arbeiten Sie vom Objekt nach außen: Sieht p11tool das Token, sieht es Zertifikat und Schlüssel, akzeptiert OpenConnect die URI, und erst dann fragen Sie, ob das Gateway die Identität akzeptiert. Jeder Schritt hat seine eigene Fehlermeldung, und jeder ist billiger zu prüfen als der nächste.