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.