Ein standardisierter Ansatz zur Zertifikate-Auswahl unter Windows

Ein detaillierter Blick darauf, wie die Windows Certificate Selection Library (WCSL) Mehrdeutigkeiten beseitigt und den Support vereinfacht.

Einleitung

Dieser Artikel beschreibt eine einheitliche Methode zum Abrufen von Zertifikaten aus dem Windows-Zertifikatspeicher. Für diejenigen, die mit Zertifikaten und dem Speicher selbst weniger vertraut sind, hier eine kurze Übersicht:

Ein Zertifikat ist an eine Entität, wie z. B. einen Webserver, gebunden und wird typischerweise verwendet, um die Identität zu beweisen (Authentifizierung), Daten zu verschlüsseln oder die Herkunft einer Nachricht zu validieren (Signaturen). Zertifikate enthalten einen öffentlichen Schlüssel und optional eine Vertrauenskette (bestehend aus CAs und root CAs). In Windows-Umgebungen ist der Windows-Zertifikatsspeicher ein gängiger Ort zur Verwaltung von Zertifikaten. Weitere Informationen finden Sie unter Microsoft-Dokumentation für Zertifikate. 

Die Herausforderung

In der Praxis wählen verschiedene Anwendungen Zertifikate aus dem Windows-Zertifikatspeicher auf inkonsistente Weise aus.

 

Beispiel:

Sowohl Anwendung A als auch Anwendung B ermöglichen die Angabe eines Alias (z. B. „localhost“) zur Identifizierung eines Zertifikats.

  • Anwendung A sucht nach dem Antragstellernamen (Subject Name)
  • Anwendung B sucht nach dem Anzeigenamen (Friendly Name)

Wenn beide mit dem Alias „localhost“ konfiguriert sind, kann Anwendung A möglicherweise erfolgreich ein Zertifikat finden, während Anwendung B dies nicht schafft.

→ Siehe Abbildung 1 für ein Beispielzertifikat, bei dem der Subject Name und der Friendly Name voneinander abweichen, was die Diskrepanz zwischen Anwendung A und B verdeutlicht.

Bild 1: Beispielzertifikat im Windows-Zertifikatsspeicher, das Unterschiede zwischen Antragstellernamen und Anzeigenamen zeigt.
Bild 1: Beispielzertifikat im Windows-Zertifikatsspeicher, das Unterschiede zwischen Antragstellernamen und Anzeigenamen zeigt.

In einem solchen Szenario müsste der Alias für Anwendung B auf 'my-friendly-name' gesetzt werden, was zu einer Abweichung in beiden Konfigurationen führen würde.

Erster Workaround: Verwendung des Hashwerts eines Zertifikats.
Obwohl dies exakte Übereinstimmungen gewährleistet, funktioniert es nicht mehr, wenn Zertifikate rotiert werden, da sich der Hash ändert. Daher wird eine bessere Lösung benötigt: eine, die die Verwendung eines Alias ermöglicht, um das richtige Zertifikat konsistent zu identifizieren – auch nach der Rotation.

Warum Standardisierung wichtig ist

In Umgebungen mit mehreren Softwareproduktlinien können Inkonsistenzen bei der Zertifikatsauswahl zu Support-Overhead, komplexer Fehlerbehebung und Rollout-Problemen führen. Ein einheitlicher Ansatz ist unerlässlich.

Um dieser Herausforderung zu begegnen, wurde ein standardisiertes Verfahren zur Auswahl von Zertifikaten nach Alias definiert. Dieses Verfahren wurde sowohl in Java als auch in C# als Windows Certificate Selection Library (WCSL) implementiert.

WCSL: So funktioniert es

Abbildung 1: Übersicht über das WCSL-Filter- und Auswahlverfahren.
Abbildung 1: Übersicht über das WCSL-Filter- und Auswahlverfahren.

Um die Auswahl von Zertifikaten anwendungsübergreifend zu standardisieren, definiert die Windows Certificate Selection Library (WCSL) ein schrittweises Verfahren, das sowohl konfigurierbar als auch deterministisch ist.

→ Eine visuelle Darstellung der WCSL-Filter- und Auswahlphasen finden Sie in Abbildung 1.

WCSL listet zunächst alle Zertifikate für den angegebenen Speicher auf. Unterstützte Speicher sind Windows-My und Windows-Root. Nach der Auflistung beginnt der Filtervorgang:

  1. Abgelaufene Zertifikate sind ausgeschlossen.
    Es werden nur Zertifikate berücksichtigt, die zur aktuellen UTC-Zeit gültig sind.
  2. Zertifikate ohne die erforderliche erweiterte Schlüsselverwendung (Extended Key Usage) werden herausgefiltert.
    Dieser Schritt lehnt Zertifikate ab, die nicht der ausgewählten erweiterten Schlüsselverwendung entsprechen (siehe RFC 5280 (Erweiterte Schlüsselverwendung)[KM1] [PP2] . Typische Filter sind SERVER_AUTH und CLIENT_AUTH. Es ist auch möglich, diesen Schritt vollständig zu überspringen.

  3. Die Alias- Übereinstimmung wird anhand mehrerer Zertifikatseigenschaften überprüft:

    Der Alias dient als Eingabe für diesen Abgleichprozess. Dieses Verhalten ist konfigurierbar. Beispielsweise kann der Abgleich auf Basis von Template und Antragstellernamen (Subject Name) basieren oder auf den Anzeigenamen (Friendly Name) beschränkt sein.

  4. Ein optionaler Schritt prüft die Existenz und Erreichbarkeit eines privaten Schüssel. 
    Wenn aktiviert, werden nur Zertifikate mit einem ladbaren privaten Schlüssel berücksichtigt. Wenn deaktiviert, werden Zertifikate ohne privaten Schlüssel – oder solche mit aufgrund von Berechtigungsproblemen unzugänglichen Schlüsseln – weiterhin eingeschlossen.

Nach Anwendung der Filterschritte ist das Ergebnis in der Regel kein oder ein passendes Zertifikat. In Ausnahmefällen, in denen mehrere Zertifikate übrig bleiben, werden zusätzliche deterministische Schritte verwendet, um eine eindeutige Auswahl zu gewährleisten

 5. Das Zertifikat mit dem spätesten Ablaufdatum wird ausgewählt.

 6. Bleibt eine Gleichheit bestehen, wird das Zertifikat mit dem jüngsten Gültigkeitsstartdatum gewählt.

 7. Wenn immer noch mehrere Zertifikate übereinstimmen, wird dasjenige mit dem alphanumerisch niedrigsten SHA1-Hash ausgewählt.

Vorteile der Verwendung von WCSL

Um ein konsistentes Verhalten über alle Anwendungen hinweg zu gewährleisten, wird WCSL mit einer standardisierten Konfiguration für die anpassbaren Schritte verwendet. Dieser Ansatz bietet mehrere entscheidende Vorteile:

  • Schnellere Fehlerbehebung
  • Einheitliches Logging
  • Reduzierte Entwicklungszeit
  • Automatische Unterstützung für die Zertifikatsrotation

Fazit

Anwendungen und Frameworks handhaben die Zertifikatsauswahl in der Regel unterschiedlich. Diese Komplexität erhöht sich, wenn unterschiedliche Bereitstellungsstrategien der Kunden berücksichtigt werden. WCSL begegnet dieser Herausforderung mit einem konfigurierbaren, flexiblen Ansatz zur Auswahl von Zertifikaten aus dem Windows-Zertifikatspeicher.

Da Implementierungen sowohl in Java als auch in C# verfügbar sind, sorgt das Verfahren für Konsistenz, reduziert den Supportaufwand und verbessert die Wartbarkeit – über alle Produkte und Umgebungen hinweg.

Organisationen, die die Zertifikatsauswahl über verschiedene Systeme und Frameworks hinweg optimieren möchten, können von der Einführung von WCSL profitieren. Die Bibliothek ist mit Java- und C#-Umgebungen kompatibel und unterstützt eine skalierbare und wartungsfreundliche Zertifikatsverwaltung.