Exchange Server 2019 and ECC certificates (Elliptic Curve Cryptography)

Since the Exchange Server April 2024 Hotfix Update, Exchange Server 2019 also supports ECC (Elliptic Curve Cryptography) certificates. However, there are a few things to bear in mind when using ECC certificates. In the following article, we take a look at what you need to consider.

What are ECC certificates

ECC certificates (Elliptic Curve Cryptography) are certificates based on elliptic curves. They offer the same security as classic RSA certificates, but require significantly shorter keys to achieve the same or higher security as RSA certificates. For example, a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) key offers the same security as a 3072-bit RSA key. Typically, 2048-bit long RSA keys are currently used for certificates, which BSI recommends (point 3.6.1), however, already use RSA keys from 3000 bits. The NIST assumes (point 3.2.1) that 2048-bit RSA keys are still considered sufficiently secure until 2030.

One problem with RSA certificates is that longer keys require more CPU resources. Especially for servers to which many connections are established, long RSA keys can have a negative impact on performance. Devices with low-performance CPUs (such as IoT devices) also have problems with 4096-bit RSA keys.

ECC offers the advantage that with a 256-bit key and SHA256 as hash algorithm, the same security as RSA with a 4096-bit key can be achieved. In addition, ECC is significantly faster than RSA, which can reduce the CPU load on servers. The speed of ECC and RSA can be compared very easily using openssl. The following command provides a quick overview (ecdsap256 corresponds to the NIST proposal ECDSA Curve P-256):

openssl speed rsa2048 rsa4096 ecdsap256

The table contains a small benchmark of my computer with WSL:

Here you can quickly see the speed advantages of ECDSA over RSA when signing. When it comes to verification, ECDSA is still almost on a par with RSA 4096. ECDSA also uses less memory than RSA.

Exchange Server 2019 and ECC certificates

If ECC certificates are used on Exchange servers, please note the following:

• The Exchange Server OAuth certificate must be an RSA certificate
• Das Verbundvertrauenszertifikat muss ein RSA-Zertifikat sein
• ECC certificates cannot be used with ADFS Claims Based Auth. can be used

Exchange Server has supported ECC certificates since the April 2024 hotfix update, but support was improved with the November 2024 security update. For example, support for IMAP and POP3 has only been available since November 2024. It should therefore be ensured that the current CUs and also the security updates are installed.

By default, ECC certificate support is disabled and must be enabled with a registry key on each Exchange server in the organization. The following registry key activates ECC support:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

It can take up to 15 minutes for the change to take effect. After activation, ECC certificates are managed in the same way as RSA certificates.

ECDSA certificates from Let's Encrypt

Let's Encrypt can already issue ECC certificates. This means that Exchange servers can be configured with ECC certificates using WIN-ACME Client, for example. In the following article, I described how the WIN-ACME Client can be used in conjunction with Exchange 2019:

• Certificate from Let's Encrypt and Exchange Server 2019

By default, WIN-ACME issues RSA certificates (currently with a key length of 3072 bits). In order for ECC certificates to be issued, only the settings_default.json file needs to be adjusted slightly and the registry key set. The rest of the configuration remains as described above. The procedure is therefore as follows:

First, the registry key is entered on all Exchange servers of the organization:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

After 15 minutes, the WIN-ACME configuration can be adjusted. Here is the customized settings_default.json:

Note: Incidentally, WIN-ACME still requested RSA certificates in my case. In my case, two CSRs were created in the directory "C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Certificates", one with RSA and the other with ECDSA:

I then renamed the directory "C:\ProgramData\win-acme" and ran WIN-ACME again. After that, only an ECC CSR was generated:

The issued certificate comes from the CA "ISRG Root X2", the newer Let's Encrypt CA, the classic RSA certificates usually come from "ISRG Root X1". However, the X2 was "cross signed" by the X1, so the certificates should be valid almost everywhere:

As usual, the WIN-ACME Client takes care of renewing the certificates.