Seit dem Exchange Server April 2024 Hotfix Update unterstützt Exchange Server 2019 auch ECC (Elliptic Curve Cryptography) Zertifikate. Beim Einsatz von ECC Zertifikaten müssen allerdings ein paar Dinge beachtet werden. Im folgenden Artikel schauen wir uns an, was es zu beachten gibt.
Was sind ECC Zertifikate
ECC Zertifikate (Elliptic Curve Cryptography) sind Zertifikate, die auf elliptischen Kurven basieren. Sie bieten dieselbe Sicherheit wie klassische RSA-Zertifikate, benötigen jedoch wesentlich kürzere Schlüssel um die gleiche oder höhere Sicherheit wie RSA Zertifikate zu erreichen. Beispielsweise bietet ein 256 Bit ECDSA (Elliptic Curve Digital Signature Algorithm) Schlüssel die gleiche Sicherheit wie ein 3072 Bit RSA Schlüssel. Typischerweise kommen aktuell 2048 Bit lange RSA Schlüssel bei Zertifikaten zum Einsatz, das BSI empfiehlt (Punkt 3.6.1) allerdings schon jetzt RSA Schlüssel ab 3000 Bit einzusetzen. Das NIST geht davon aus (Punkt 3.2.1), dass 2048 Bit RSA Schlüssel noch bis 2030 als ausreichend sicher gelten.
Ein Problem der RSA Zertifikate ist, dass bei längeren Schlüsseln, mehr CPU Ressourcen benötigt werden. Gerade bei Servern zu denen viele Verbindungen aufgebaut werden, können lange RSA Schlüssel die Performance negativ beeinflussen. Auch Geräte mit leistungsschwachen CPUs (wie etwa IoT Geräte) haben Probleme mit 4096 Bit RSA Schlüsseln.
ECC bietet hier den Vorteil das mit einem 256 Bit Schlüssel und SHA256 als Hashalgorithmus die gleiche Sicherheit wie RSA mit 4096 Bit Schlüssel erreicht werden kann. Zusätzlich ist ECC deutlich schneller als RSA, dies kann bei Servern die CPU Last senken. Mittels openssl kann sehr einfach die Geschwindigkeit von ECC und RSA verglichen werden, einen schnellen Überblick liefert der folgende Befehl (ecdsap256 entspricht dem NIST Vorschlag ECDSA Curve P-256):
openssl speed rsa2048 rsa4096 ecdsap256
In der Tabelle findet sich mal ein kleiner Benchmark von meinem Rechner mit WSL:
sign/s | verify/s | |
RSA 2048 Bit | 2.568 | 86.281 |
RSA 4096 Bit | 363 | 22.987 |
ECDSA Curve P-256 | 67.976 | 21.566 |
Hier kann man schnell die Geschwindigkeitsvorteile von ECDSA beim Signieren gegenüber RSA erkennen. Beim Verifizieren liegt man immerhin noch nahezu gleich auf zu RSA 4096. Auch verbraucht ECDSA weniger Speicher als RSA.
Exchange Server 2019 und ECC Zertifikate
Wenn auf Exchange Servern ECC Zertifikate zum Einsatz kommen gibt es folgendes zu beachten:
- Das Exchange Server OAuth-Zertifikat muss ein RSA-Zertifikat sein
- Das Verbundvertrauenszertifikat muss ein RSA-Zertifikat sein
- ECC Zertifikate können nicht mit ADFS Claims Based Auth. Verwendet werden
Exchange Server unterstützen seit dem April 2024 Hotfix Update ECC Zertifikate, die Unterstützung wurde allerdings mit dem November 2024 Sicherheitsupdate verbessert. Beispielsweise gibt es erst seit dem November 2024 Unterstützung für IMAP und POP3. Es sollte also sichergestellt werden, das die aktuellen CUs und auch die Sicherheitsupdates installiert sind.
In der Standardeinstellung ist die Unterstützung von ECC Zertifikaten deaktiviert und muss mit einem Registry Key auf jedem Exchange Server der Organisation aktiviert werden. Der folgende Registry Schlüssel aktiviert die ECC Unterstützung:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String
Es kann bis zu 15 Minuten dauern, bis die Änderung wirksam wird. Nach der Aktivierung werden ECC Zertifikate auf gleiche Weise verwaltet wie auch RSA Zertifikate.
ECDSA Zertifikate von Let’s Encrypt
Let’s Encrypt kann bereits ECC Zertifikate ausstellen. Somit lassen sich Exchange Server beispielsweise mittels WIN-ACME Client mit ECC Zertifikaten konfigurieren. In dem folgenden Artikel hatte ich beschrieben, wie der WIN-ACME Client in Verbindung mit Exchange 2019 genutzt werden kann:
In der Standardeinstellung besorgt WIN-ACME RSA Zertifikate (aktuell mit 3072 Bit Schlüssellänge). Damit ECC Zertifikate ausgestellt werden, muss nur die settings_default.json Datei etwas angepasst werden und der Registry Key gesetzt werden. Die restliche Konfiguration bleibt wie oben beschrieben. Die Vorgehensweise ist daher wie folgt:
Zuerst wird der Registry Key auf allen Exchange Servern der Organisation eingetragen:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String
Nach 15 Minuten kann dann die WIN-ACME Konfiguration angepasst werden. Hier die angepasste settings_default.json:
Hinweis: WIN-ACME hat in meinem Fall übrigens trotzdem RSA Zertifikate angefordert. Bei mir waren im Verzeichnis „C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Certificates“ zwei CSRs erzeugt worden, einer mit RSA der andere mit ECDSA:
Ich habe dann das Verzeichnis „C:\ProgramData\win-acme“ umbenannt und WIN-ACME neu durchlaufen lassen. Danach wurde nur noch ein ECC CSR erzeugt:
Das ausgestellte Zertifikat kommt dann übrigens von der CA „ISRG Root X2“, die neuere Let’s Encrypt CA, die klassischen RSA Zertifikate kommen in der Regeln von „“ISRG Root X1“. Die X2 wurde aber von der X1 „cross signed“, daher sollten die Zertifikate nahezu überall gültig sein:
Die Erneuerung der Zertifikate übernimmt wie gehabt der WIN-ACME Client.
Hi,
hoffen wir mal, dass die aktuellen Einschränkungen
„Das Exchange Server OAuth-Zertifikat muss ein RSA-Zertifikat sein
Das Verbundvertrauenszertifikat muss ein RSA-Zertifikat sein
ECC Zertifikate können nicht mit ADFS Claims Based Auth. Verwendet werden“
Auch noch irgendwann behoben werden. Denn so wie es aktuell ist, dürfte der Einsatz von on-prem modern auth mit ADFS nur mit RSA Zertifikate funktionieren, oder?
Am Edge Server funktionieren jetzt ECC Zertifikate auch, ich nehme an, dass deswegen der Switch auf Registry anstatt Settings override stattfand.