Übersicht Zertifikatsnutzung
Für die Marktkommunikation via API Webservices sind eigene Zertifikate notwendig die bestimmten Anforderungen (beschrieben in Regelungen zum Übertragungsweg für API-Webdienste V1.1) der CP(Certificate Policy) der SM-PKI entsprechen müssen:
- Erstellung der Zertifikate erfolgt mit dem brainpoolP256r1 Kurvenparameter
- CommonName (CN) muss dem Schema
.EMT.API entsprechen. - Organisational Unit (OU) muss die MP-ID des Tenants sein.
- URL enthält die Adresse des genutzten Verzeichnisdienstes.
- ein EMT.API Zertifikat kann für ein oder mehrere API-Webdienste genutzt werden.
Die Umsetzung der Hash- und Signatur-Algorithmen wird in TR03116-3, Stand: 2023 beschrieben
mTLS
Bei mTLS authentifizieren sich Client und Server gegenseitig. Dafür wird das TLS Zertifikat und das Aussteller Zertifikat beim starten der Services geladen und im Truststrore/Keystore gespeichert. Es wird TLS 1.2 verwendet
mTLS - Outbound (Client):
Benötigte Zertifikate:
- Sender (Mandant) TLS-Zertifikat & Schlüssel
- Empfänger (Partner) Aussteller Zertifikat
Folgende Services setzen mTLS Outbound ein:
- api-webservice-server
- api-webservice-client
- api-address-service (für Anfragen gegenüber API-Verzeichnisdiensten)
- CSR-Service (für die Zertifikatserneuerung gegenüber der eigenen Sub-CA)
- Certificate-Manager (für die LDAPS Abfrage der Partner-Zertifikate bei den Sub-CAs
mTLS - Inbound (Server):
Benötigte Zertifikate:
- Empfänger (Mandant) TLS-Zertifikat & Schlüssel
- Sender (Partner) Aussteller Zertifikate
Nachrichten-Signatur
Im Folgenden werden Signaturen für API-Anfragen betrachtet.
Der api-webservice-client signiert ausgehende API-Anfragen und der api-webservice-server prüft die Signatur empfangener API-Anfragen.
Signieren API-Anfrage (Outbound):
Benötigte Zertifikate:
- Mandant (Sender) SIGN-Zertifikat & Schlüssel
Signatur Verifikation API-Anfrage (Inbound):
Benötigte Zertifikate:
- Partner (Sender) Aussteller Zertifikat
Anhang Verschlüsselung
Neben der TLS Verschlüsselung ist keine zusätzliche Verschlüsselung vom BDEW vorgesehen.
Zertifikats-Lebenszyklus
Alle Zertifikate werden im FSS bzw. über die FSS-UI verwaltet.
Mandanten-Zertifikate werden mit Hilfe des CSR-Service erstellt & erneuert. Der Service verbindet sich hierfür mit den Webservices der Sub-CAs.
Partner Zertifikate können automatisch über den Certificate-Manager geladen und erneuert werden. Dieser verbindet sich hierfür mit dem LDAP der Sub-CAs.
Aussteller-Zertifikate sind manuell über die FSS-UI zu pflegen.
Sperrlisten
Sperrlisten müssen regelmäßig (mindestens 1x täglich) heruntergeladen und im FSS hinterlegt werden. Nur so kann der Einsatz gesperrter Zertifikate verhindert werden. Gelingt der Aufruf mindestens 3 Tage lang nicht, ist dem, Zertifikat gemäß BDEW Spezifikation zu misstrauen und darf nicht mehr verwendet werden.
Der Sperrlisten-Download kann z.B. automatisch über den Service CSR-Downloader durchgeführt werden. Dieser greift auf die durch die Sub-CAs veröffentlichten Sperrlisten zu.
Spätestens 10 Werktage, bevor Zertifikate ungültig werden, muss der Inhaber dieser Zertifikate die Nachfolgezertifikate zur Verfügung gestellt haben.
View Me Edit Me