EMT.API-Zertifikate

Beantragung

Bevor der Betrieb den Lieferantenwechsel 24h starten kann, müssen Zertifikate im API-Server hinterlegt werden. Diese Zertifikate werden von der SM-PKI des BSI ausgestellt und müssen vorher beantragt werden.

Die Beantragung erfolgt im Namen durch die SIV im Namen des Inhabers der jeweiligen Marktpartner-ID. Die SIV beantragt die Zertifikate beim Dienstleister DARZ, der eine Sub-CA der SM-PKI betreibt.

Voraussetzungen für die Beantragung

Schlüsselzeremonie

Unter EMT.API-Zertifikate - Wissensdatenbank - Confluence wird beschrieben, was hier zu tun ist. Vorher muss allerdings bestimmt werden, die die Hostnamen (und Portnummern) der öffentlich verfügbaren API-Endpunkte lauten.

Einrichtung

Reverse-Proxy (eingehend)

Die Einrichtung des Transportweges in eingehende Richtung wird auf Empfehung der SIV mit haproxy realisiert. Wichtig hierbei sind folgende Kriterien:

• Lenkung des Traffics zum richtigen Backend-Server anhand des SNI
• Übergabe des Traffics nicht wie ein üblicher Reverse-Proxy auf dem HTTP-Level, sondern auf TCP-Level, damit mTLS auch weiterhin funktioniert. Das bedeutet, dass der Reverse-Proxy selbst keine Zertifikate und Schlüssel für den Betrieb benötigt, da die TLS-Verbindungen erst am Ziel (hier: API-Server) terminieren.
• Nutzung einer gemeinsamen externen IP-Adresse für die in der Schlüsselzeremonie ermittelten Hostnames

In der Tabelle sind die aktuellen Konfigurationen im haproxy dargestelt.

• Hostname: Name, über den der Datenverkehr von außen initiiert wird
• externe IP-Adresse: zu dieser Adresse wird der Hostname aufgelöst. Alle Hostnames teilen sich die gleiche Adresse
• DNAT-Ziel: In der Firewall wird dieser DNAT-Regel konfiguriert. Hiermit wird jede Anfrage, die auf der externen IP-Adresse landet, zum Reverse-Proxy durchgereicht
• Der Reverse-Proxy gibt die Anfragen basierend auf dem SNI an das jeweilige Backend weiter.

#           ┌──────────────────────────────┐
            │      Externer Client         │
            └─────────────┬────────────────┘
                          │
                          │ DNS-Auflösung:
                          │ "netz.webapi.stadtwerke-ilmenau.de" 
                          │ oder "vertrieb.webapi.stadtwerke-ilmenau.de"
                          │  → ergibt31.3.87.155
                          │
                          ▼
            ┌──────────────────────────────┐
            │     Externe IP: 31.3.87.155  │
            └─────────────┬────────────────┘
                          │
                          │ DNAT-Regel in der Firewall:
                          │ Jede Anfrage an 31.3.87.155
                          │ wird weitergeleitet an:
                          │ 10.5.3.101:5443
                          │
                          ▼
            ┌──────────────────────────────┐
            │   Reverse-Proxy (haproxy)    │
            │       (TCP-Level)            │
            │    SNI-Auswertung der TLS    │
            └─────────────┬────────────────┘
                          │
              ┌───────────┴───────────────┐
              │                           │
              ▼                           ▼
   ┌─────────────────────┐       ┌─────────────────────┐
   │ Backend:            │       │ Backend:            │
   │ 192.168.24.229:5124 │       │ 192.168.24.230:5124 │
   │ (netz.webapi...)    │       │ (vertrieb.webapi..) │
   └─────────────────────┘       └─────────────────────┘

Erklärung der Grafik:

1. Externer Client & DNS-Auflösung:
   Der Client initiiert die Verbindung über einen der beiden Hostnamen. Beide Hostnamen lösen auf dieselbe externe IP-Adresse (1.2.3.4) auf.
2. Firewall-DNAT:
   Sobald die Anfrage bei der externen IP (1.2.3.4) ankommt, sorgt die konfigurierten DNAT-Regel dafür, dass die Anfragen an den Reverse-Proxy (10.5.3.101:5443) weitergeleitet werden.
3. Reverse-Proxy (haproxy und TCP-Level):
   Der Reverse-Proxy empfängt die Anfragen auf TCP-Niveau und wertet das SNI-Feld in der TLS-Verbindung aus, um zu ermitteln, an welches Backend das Paket weitergeleitet wird. Somit bleibt die verschlüsselte mTLS-Verbindung bis zum Zielserver intakt.
4. Backend-Ziele:
   Abhängig vom SNI wird der Traffic entweder an:

• • das Backend „netz.webapi.stadtwerke-ilmenau.de“ (192.168.24.229:5124) oder
  • an das Backend „vertrieb.webapi.stadtwerke-ilmenau.de“ (192.168.24.230:5124) weitergeleitet.

Quelle: EMT.API-Zertifikate - Wissensdatenbank - Confluence