Fedora Account System
Red Hat Associate
Red Hat Customer
The sendmail.mc included with Fedora contains the following line: define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl However, because of https://fedoraproject.org/wiki/Changes/droppingOfCertPemFile, this file no-longer exists. The following messages appear in the journal: STARTTLS=client: file /etc/pki/tls/certs/ca-bundle.crt unsafe: No such file or directory STARTTLS=client, error: load verify locs /etc/pki/tls/certs, /etc/pki/tls/certs/ca-bundle.crt failed: 0 STARTTLS=client, relay=smtp.gmail.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 ruleset=tls_server, arg1=FAIL, relay=smtp.gmail.com, reject=454 4.7.0 authentication failed STARTTLS: read error=generic SSL error (-1), errno=9, get_error=error:0A000126:SSL routines::unexpected eof while reading, retry=1, ssl_err=1 Sending fails.
IMHO replacement by the `confCACERTPath` may do the trick, let me check.
See the following curiosity in /usr/share/doc/sendmail/op.pdf. 5.7. O — Set Option ... CACertPath Path to directory with certificates of CAs. This directory directory must contain the hashes of each CA certificate as filenames (or as links to them). CACertFile File containing one or more CA certificates; see section about STARTTLS for more infor- mation. ... 6.6.1. Certificates for STARTTLS When acting as a server, sendmail requires X.509 certificates to support STARTTLS: one as certifi- cate for the server (ServerCertFile and corresponding private ServerKeyFile) at least one root CA (CAC- ertFile), i.e., a certificate that is used to sign other certificates, and a path to a directory which contains (zero or more) other CAs (CACertPath). The file specified via CACertFile can contain several certifi- cates of CAs. The DNs of these certificates are sent to the client during the TLS handshake (as part of the CertificateRequest) as the list of acceptable CAs. However, do not list too many root CAs in that file, otherwise the TLS handshake may fail In my testing, confCACERT_PATH seemed to be ignored if confCACERT was not set to a file that existed. The following worked for me (despite this containing what you might expect to be "too many root CAs" as cautioned against in the above documentation): define(`confCACERT', `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem')dnl
Yes, it doesn't work. IMHO it should work the same way as in the Postfix. I.e. if the client verification is disabled (confTLS_SRV_OPTIONS is V) and confCACERT is not set, it shouldn't send the DNs from the bundle and the TLS should work. I will forward it to the sendmail upstream. In the meantime you will need to workaround it.
IMHO for the out-of-the-box functionality we could probably use the self-signed certificate instead of the bundle, but people switching to their own certificates will have to reconfigure the CACERT, e.g.: define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl define(`confCACERT', `/etc/pki/tls/certs/sendmail.pem')dnl define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl define(`confSERVER_KEY', `/etc/pki/tls/private/sendmail.key')dnl
Reply from sendmail upstream: > In sendmail the options CACertPath and CACertFile are for both > server and client -- in contrast to postfix. > This makes it hard to disable one or both of those options just for > the server. > > However, I added your suggestion to my (long) "to do" list > to look for a possible enhancement.
Please check if the workaround from comment 4 works for you without any side effect. IMHO it should be safe, the private key should be in the sendmail.key and shouldn't leak in such configuration. In case of no objection I will probably use this workaround in Fedora until upstream comes up with better solution.
*** Bug 2487008 has been marked as a duplicate of this bug. ***
OK, no objection, let's go with the workaround.
FEDORA-2026-4009c22a92 (sendmail-8.18.2-4.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-4009c22a92
FEDORA-2026-32f7485395 (sendmail-8.18.2-4.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-32f7485395
FEDORA-2026-4009c22a92 (sendmail-8.18.2-4.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-32f7485395 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-32f7485395` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-32f7485395 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-32f7485395 (sendmail-8.18.2-4.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Hello. As a quick workaround, this also worked for me: ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/pki/tls/certs/ca-bundle.crt systemctl restart sendmail Probably not a long-term fix though.