Ü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