[ACME] add support for ECDSA and phase out RSA

[apio-sys]

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree to them.

What does this PR include?

Short Description

These changes aim to implement ECDSA certificates without disturbing an existing environment. There is no choice or setting to prefer RSA or ECDSA to avoid confusion. Anything new should be based on modern standards and RSA should be phased out progressively. So on a new instance, everything will be clean from the start. On an existing instance, everything will continue to work with RSA including when adding new domains unless the administrator decides to replace the RSA certificates with ECDSA by deleting them and let the script recreate everything needed (based on the other cert/SAN preferences in mailcow.conf of course). Inspired from the way Certbot handles this in recent releases.

See also the discussion in #2426 which is open since 2019.

Main motivation: the currently used certificates do not pass Internet.nl tests (for instance) hence are not future-ready.

The public key of at least one of your mail server certificates is based on a signing algorithm with parameters that should be phased out
as they are weaker, although you might still use them if absolutely
needed. In a future update, they will likely become insufficient.

Technical details:

Mail server (MX)	Outdated signature parameter
mail.domaine.fr.	R12: RSAPublicKey-2048
...	phase out

echo | openssl s_client -connect mail.domaine.fr:25 -starttls smtp -showcerts 2>/dev/null | awk '/-----BEGIN CERT/{n++} n==2' | openssl x509 -noout -text | grep -E "Subject:|Public-Key"
    Subject: C = US, O = Let's Encrypt, CN = R12
    Public-Key: (2048 bit)

Affected Containers

• acme-mailcow

Did you run tests?

What did you test?

• The fact that is doesn't interfere with an existing installation;
• That one can add domains on an existing installation but not yet opt-in for ECDSA certificates and all continues to work;
• That one can swap the server to modern standards by deleting the existing keys and let the script recreate them.

What were the final results?

• There is indeed no change on an existing installation. The RSA keys continue to function and will renew in their same format (until some date in the future when LE might retire that format altogether but that is probably still a few years away).
• One can continue to add domains and still continue to use the legacy environment if one is not yet ready to plan the change-over.
• Once ready to change existing and future domains on the mailcow instance, follow these steps:

 # Delete old keys and force regeneration
rm data/assets/ssl/acme/key.pem
rm data/assets/ssl/[mailcow_instance]/key.pem
touch data/assets/ssl/force_renew

# Rebuild and restart
docker compose build acme-mailcow
docker compose up -d acme-mailcow

# Watch the logs
docker compose logs -f acme-mailcow

Once the new certificates in place, one needs to update all depending TLSA records. These can be found as usual in the UI in E-Mail > Configuration > Domains > Domains > [domaine.fr] > DNS. TLSA records should typically have a short TTL, i.e. no more than 3600. It is worth checking beforehand if these records didn't have an abnormal long TTL which can otherwise result in email delivery failures during the change-over period and as long as the TTL itself.

• When testing again, there is no more RSA phased-out warning:

The public keys of all your mail server certificates are based on a secure signing algorithm with secure parameters.

Technical details:

Mail server (MX)	Outdated signature parameter
mail.domaine.fr.	None

echo | openssl s_client -connect mail.domaine.fr:25 -starttls smtp -showcerts 2>/dev/null | awk '/-----BEGIN CERT/{n++} n==2' | openssl x509 -noout -text | grep -E "Subject:|Public-Key"
   Subject: C = US, O = Let's Encrypt, CN = E8
   Public-Key: (384 bit)

If this PR is acceptable and accepted, I shall endeavor to add the above change-over instructions in the mailcow-dockerized-docs repo.

[apio-sys]

Could we get this at least in the nightly so that extensive testing can be done beyond what I did? I think this will be very beneficial to have included in the stable version as soon as possible.

[apio-sys]

Any chance of getting this merged? Or discuss further if needed?