On Fri, Jun 2, 2023 at 2:20 PM Tim Woodall <debianu...@woodall.me.uk> wrote: > > Anyone come across delivery failures where the client cert is signed by > an internal ca.
Are you sure it's not a self-signed end-entity certificate used in an Opportunistic Encryption scheme? https://en.wikipedia.org/wiki/Opportunistic_encryption#E-mail > Jun 2 03:45:27 imap202 sm-mta[14736]: STARTTLS=server, error: accept > failed=-1, reason=tlsv1 alert unknown ca, SSL_error=1, errno=0, retry=-1, > relay=mta140.fwdto.net [195.68.228.140] > Jun 2 03:45:27 imap202 sm-mta[14736]: 3523jQ45014736: mta140.fwdto.net > [195.68.228.140] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v4 > > I've not seen this before. It was persistent - tried 75 times over 5 > hours before it gave up. > > I don't have an easy way to get an email resent from this host. I've > hopefully disabled STARTTLS for it now... The TLS RFC's say the certificate chain must be sent when needed. Including the Root CA is optional. Usually a relying party needs to have the Root CA on-hand before using it. However, sending the Root CA has use cases; for example, in a Trust-on-First-Use (TOFU) scheme. You may be able to obtain the Root CA with openssl's s_client. I was not able to get them to work, however. They just hung. Maybe you can get one of them to work. $ openssl s_client -showcerts -starttls imap -connect mta140.fwdto.net:139 ^C $ openssl s_client -showcerts -starttls pop3 -connect mta140.fwdto.net:110 ^C $ openssl s_client -showcerts -starttls pop3 -connect mta140.fwdto.net:993 ^C $ openssl s_client -showcerts -starttls smtp -connect mta140.fwdto.net:587 ^C $ openssl s_client -showcerts -starttls smtp -connect mta140.fwdto.net:465 ^C $ openssl s_client -showcerts -starttls smtp -connect mta140.fwdto.net:25 ^C Jeff