On Sat, Apr 09, 2022 at 10:55:03AM +0200, Admin Beckspaced wrote:

> > That host has an ECDSA P384 certificate.  This is liable to not be
> > supported by older systems.  For maximum interoperability, RSA is safer,
> > or with ECDSA perhaps P256, though likely that too is not supported by
> > a peer that lacks P384.
> 
> so you are saying that the mailserver I host (mail.beckspaced.com) is 
> using a 'new' cert which is not compatible with older systems?

Its certificate is bears a public key from a more recently established
"elliptic curve" (ECDSA) cryptosystem, whereas only the original RSA is
supported by some older systems.

A sufficiently robust implementation of unauthenticated opportunistic
TLS in SMTP, i.e. one that ensures *delivery* with the maximum
*available* security, would fall back to cleartext after failing to
establish a TLS connection.  Apparently the sending system is not
robust in this way, and does not support ECDSA.

> So I can either ask the other host to update their exchange server and 
> certificates?

The sending system's certificates are irrelevant here.  All that matters
is the feature set of their TLS libraries and any explicit crypto
algorithm choices set by the administrator.

You may have trouble convincing the sending system's administrator to
perform a software upgrade just to send email to your system.  Of course
there are other systems with ECDSA certificates, but they are not very
common yet, so the problem may appear to be restricted just to you, and
then you get the blame.

> Or switch my cert to RSA for better compatibility?

This is my recommendation.

On Sat, Apr 09, 2022 at 11:15:37AM +0200, Josef Vybíhal wrote:

> smtpd_tls_cert_file = /etc/postfix/tls/rsa/_.acme.com.rsa.fullchain.pem
> smtpd_tls_eccert_file = /etc/postfix/tls/ecc/_.acme.com.ecc.fullchain.pem
> smtpd_tls_eckey_file = /etc/postfix/tls/ecc/_.acme.com.ecc.key
> smtpd_tls_key_file = /etc/postfix/tls/rsa/_.acme.com.rsa.key
> 

Dual certificates require some skill to maintain.  I don't recommend
this at present.  This is an advanced use case that most users would
best avoid.

--
    Viktor.

Reply via email to