Prüfung der in Zustellpunkten hinterlegten Zertifikate (Part I) [M]
Warum?
In der Produktivumgebung muss der Zustelldienst die Verwendung von Zertifikaten aus der V-PKI überprüfen und technisch erzwingen. Im Gegensatz zur Testumgebung dürfen hier keine selbstsignierten Zeritifkate verwendet werden.
Referenzen / Infos
- In folgendem Issue (#142 (closed)) wird die Prüfung durch den Nutzer dokumentiert. Arbeiten an der Implementierung der Prüfung im Zustelldienst können idealerweise für die Dokumentation und Codebeispiele nachgenutzt werden.
- Root-Zertifikate: https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Verwaltungs-PKI/Wurzelzertifizierungsstelle/Zertifikate/zertifikate_node.html
- Nimbus nutzt die JCA (Java Cryptography Architecture) des JDK/JRE per default zum Prüfen der Zertifikate und Signaturen. BouncyCastle ist ein alternativer Provider, der von Nimbus unterstützt wird
- CEF Digital hat eine Bibliothek entwickelt (Digital Signature Service), die u.a. auch Zertifikate validieren kann:
- Implementierung kann in #297 (closed) wiederverwendet werden bzw. wird dort bereits umgesetzt.
- Technische Richtlinie TR02103: X.509-Zertifikate und Zertifizierungspfadvalidierung des BSI
Akzeptanzkriterien
-
Keys werden auf Gültigkeit inkl. der hinterlegten Zertifikatskette geprüft -
Überprüfung, dass der JWK eine Schlüssellänge von mind. 4096 Bits aufweist. -
Wenn der Parameter use
angegeben ist, dann muss beiuse=sig
zwingend der Wertkey_ops=verify
und beiuse=enc
zwingend der Wertkey_ops=wrapKey
gesetzt sein. Alternative Umsetzung: Der Zustelldienst wift einen Fehler, wenn dasuse
-Attribut angegeben ist. Siehe https://datatracker.ietf.org/doc/html/rfc7517#section-4.3 -
Der im Attribut x5c
hinterlegte öffentliche Schlüssel muss mit dem Schlüssel im JWK (Attributen
unde
) übereinstimmen. -
Die im x5c
hinterlegte Zertifikatskette ist gültig, d.h. die folgenden Anforderungen sind eingehalten:-
Die Einhaltung der Vorgaben aus https://datatracker.ietf.org/doc/html/rfc7517#section-4.7 wird durch den Zustelldienst technsich erzwungen. -
Das x5c
-Attribut enthält genau drei Zertifikate (Zertifikatskette bestehend aus Zertifikat, CA-Zertifikat (DOI-CA) und Root-Zertifikat). Gemäß https://datatracker.ietf.org/doc/html/rfc7517#section-4.7 müssen die Zertifikat in genau dieser Reihenfolge angegeben sein. - Es wurde überprüft, dass der öffentliche Schlüssel mit dem im JSON Web Key hinterlegten Zertifikat übereinstimmt (Attribute n und e) -
Es wurde die Zertifikats-Kette bis zum Wurzelzertifikat (BSI) überprüft. -
Es wurde die Zertifikats-Kette mittels eines Validierungsdienstes (gegen eine Certificate Revocation List (CRL) und/oder einen OCSP-Endpunkt) mit signierten Antworten überprüft
-
-
-
Keys, die Anforderungen nicht erfüllen, können nicht hochgeladen und nicht abgerufen werden. -
Eine vollständige Prüfung wird beim Upload, vor der Speicherung, überprüft -
Eine vollständige Prüfung wird vor der Herausgabe über die API überprüft (Erläuterung: Wird das hinterlegte Zertifikat nach dem Upload zurückgezogen oder für ungültig erklärt, dann darf dieses Zertifikat nicht abgerufen werden können.)
-
-
Für den Betrieb in der Testumgebung besteht die Möglichkeit, die Prüfung von Zertifikaten via Config-Flag abzuschalten. In der Testumgebung ist insb. die Nutzung von selbst-erstellen JWKs ohne Zertifikat aus einer PKI möglich. -
Root-Zertifikate müssen beim Dienst hinterlegt werden und regelmäßig auch auf Aktualisierung überprüft werden (hinsichtlich neuer Zertifikate [aktuell ein paar mal im Jahr kommt ein neues dazu]) -
Neu: Die Prüfung erfolgt auch, wenn sie abgeschaltet ist. Dabei werden jedoch nur Fehler geloggt. Die Fehler/Exceptions werden im letzten Schritt jedoch ignoriert. -
Neu: Die Vorgaben der Technische Richtlinie TR02103 sind eingehalten. -
Es wurde ein Follow-Up-Ticket zum Prüfen der Logs und Schafschalten der Config angelegt. (#575 (closed))
Edited by Michael Miera