EMT.API-Zertifikate
Alle in rot gekennzeichneten Platzhalter müssen noch ergänzt werden. Hier fehlen noch die entsprechenden realen Werte.
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
Benötigt | Zuständig | Kommentar | Erledigt |
Zuteilungsurkunde | |||
Aktueller Handelsregisterauszug | |||
Vollmacht für die SIV.AG zur Beantragung des Zertifikatstripels bei der DARZ | |||
CRMF-Datei | IT | Wird über Schlüsselzeremonie erstellt |
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.
Marktpartner-ID | Bereich | URL |
????? | Netz | ????.netz.webapi.stadtwerke-ilmenau.de |
????? | Vertrieb | ????.vertrieb.webapi.stadtwerke-ilmenau.de |
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.
Hostname | externe IP-Adresse | DNAT-Ziel FWL (Reverse-Proxy) | Backend-Ziel |
????.netz.webapi.stadtwerke-ilmenau.de | 1.2.3.4 | 10.5.3.101:5443 | 5.6.7.8:5124 |
????.vertrieb.webapi.stadtwerke-ilmenau.de | 1.2.3.4 | 10.5.3.101:5443 | 5.6.7.9:5124 |
# ┌──────────────────────────────┐
│ Externer Client │
└─────────────┬────────────────┘
│
│ DNS-Auflösung:
│ "netz.webapi.stadtwerke-ilmenau.de"
│ oder "vertrieb.webapi.stadtwerke-ilmenau.de"
│ → ergibt 1.2.3.4
│
▼
┌──────────────────────────────┐
│ Externe IP: 1.2.3.4 │
└─────────────┬────────────────┘
│
│ DNAT-Regel in der Firewall:
│ Jede Anfrage an 1.2.3.4
│ wird weitergeleitet an:
│ 10.5.3.101:5443
│
▼
┌──────────────────────────────┐
│ Reverse-Proxy (haproxy) │
│ (TCP-Level) │
│ SNI-Auswertung der TLS │
└─────────────┬────────────────┘
│
┌───────────┴───────────────┐
│ │
▼ ▼
┌────────────────────┐ ┌────────────────────┐
│ Backend: │ │ Backend: │
│ 5.6.7.8:5124 │ │ 5.6.7.9:5124 │
│ (netz.webapi...) │ │ (vertrieb.webapi..)│
└────────────────────┘ └────────────────────┘Erklärung der Grafik:
- 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. - 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. - 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. - Backend-Ziele:
Abhängig vom SNI wird der Traffic entweder an:
- das Backend „netz.webapi.stadtwerke-ilmenau.de“ (5.6.7.8:5124) oder
- an das Backend „vertrieb.webapi.stadtwerke-ilmenau.de“ (5.6.7.9:5124) weitergeleitet.