Today I started getting failures sending messages from Thunderbird to my FreeBSD SMTP server about not recognizing the certificate issuer, Let's Encrypt. This hasn't been an issue in the past. I got around the problem by importing the LE intermediate certificate directly into Thunderbird. But that seems wrong. After some debugging (and asking Claude for some rapid troubleshooting -- so salt grains as appropriate), here are the findings on how this might be resolved for anyone else who runs into this issue... The mail/sendmail port ships with TLS_CERT_CHAIN=off in the default pkg binary build. This option controls whether sendmail is compiled to use OpenSSL's SSL_CTX_use_certificate_chain_file() vs SSL_CTX_use_certificate_file() when loading the server certificate. With TLS_CERT_CHAIN=off, only the leaf certificate is presented during the TLS handshake, regardless of whether ServerCertFile points to a file containing a full chain. Intermediate certificates in the file are silently ignored. IMPACT Any sendmail installation using a certificate issued by an intermediate CA -- which includes all Let's Encrypt certificates -- will present an incomplete chain to connecting clients and peer MTAs. Clients performing strict chain validation will fail to verify the certificate. This is increasingly common as major mail providers (Google, Microsoft) have tightened TLS certificate validation requirements for inbound SMTP connections. There is no workaround available through sendmail configuration alone. The O ServerChainFile directive referenced in some documentation does not exist as a recognized sendmail option. Pointing confSERVER_CERT at a fullchain.pem containing both leaf and intermediate has no effect without TLS_CERT_CHAIN=on because the wrong OpenSSL API call is used. STEPS TO REPRODUCE 1. Install sendmail-8.18.2 from pkg on FreeBSD 14.x 2. Configure confSERVER_CERT to point at a Let's Encrypt fullchain.pem (leaf + E8 intermediate) 3. Start sendmail and run: openssl s_client -connect localhost:25 -starttls smtp 2>&1 | grep -A6 "Certificate chain" Only depth 0 (leaf) is presented. The Let's Encrypt E8 intermediate is absent from the handshake. Confirming the binary was built without chain support: pkg info sendmail | grep TLS_CERT_CHAIN TLS_CERT_CHAIN : off EXPECTED BEHAVIOR When ServerCertFile contains a chained PEM (leaf + intermediates), sendmail should present the full chain during the TLS handshake. This is standard behavior for all other MTAs (Postfix, Exim, Dovecot) and is what remote MTAs and mail clients expect. PROPOSED FIX Change the default for TLS_CERT_CHAIN from off to on in mail/sendmail/Makefile. This is a one-line change. The option has existed in the port for some time and is fully supported by the sendmail binary -- it simply is not enabled in the default pkg build. Users who have rebuilt from ports with TLS_CERT_CHAIN=on confirm this resolves the issue.
TLS_CERT_CHAIN does not control if the intermediate is send. TLS_CERT_CHAIN controls from which file it is read. I have "TLS_CERT_CHAIN : off" in production /usr/local/bin/openssl s_client -connect xxxxxxxxxxx:25 -starttls smtp -showcerts Certificate chain 0 s:CN=xxxxxxxxxxx i:C=US, O=Let's Encrypt, CN=R12 a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: Mar 8 00:36:03 2026 GMT; NotAfter: Jun 6 00:36:02 2026 GMT 1 s:C=US, O=Let's Encrypt, CN=R12 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT 2 s:C=US, O=Internet Security Research Group, CN=ISRG Root X1 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: Jun 4 11:04:38 2015 GMT; NotAfter: Jun 4 11:04:38 2035 GMT If sendmail can not found your intermediate certificate, it will not send the chain. confSERVER_CERT is not the place for the intermediate certificate. If it worked with an old intermediate, you missed to update a file. $ less /usr/local/share/sendmail/cf/README /STARTTLS $ less /usr/local/share/doc/sendmail/op.txt /Certificates for STARTTLS
Dirk, thank you for the direction, and apologies for the run-around. As you said, this is not a TLS_CERT_CHAIN build option issue. The fix required a change to confCACERT to point at chain.pem. For the longest time this was just set up wrong, and apparently Thunderbird has recently become more sensitive to this. You could say that Thunderbird became a canary. :-) Closing this ticket.