Bug 1565341

Description of problem:
In a common scenario, a sendmail admin would like to provide STARTTLS
for inbound e-mails but also perform certificate verification for outbound
e-mails, while the latter is maybe not enforced for all destination hosts;
the sendmail default is just to log e.g. "verify=FAIL" or "verify=OK" for
outbound e-mails if the remote host offered STARTTLS.

For above, /etc/mail/sendmail.mc looks usually more or less like this:

define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
define(`confSERVER_CERT', `/etc/pki/tls/certs/mail.example.net.pem')dnl
define(`confSERVER_KEY', `/etc/pki/tls/private/mail.example.net.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl

It provides the /etc/pki/tls/certs/ca-bundle.crt root CA bundle to allow
verification of outbound SSL/TLS connections, also adds /etc/pki/tls/certs
directory in case of company-internal CAs that shall be handled as well,
but are not publically trusted (put *.pem in that dir, then c_rehash(1)).

Put the public SSL certificate into /etc/pki/tls/certs/mail.example.net.pem
and the private key into /etc/pki/tls/private/mail.example.net.key. The 'V'
is used to not ask the client for a SSL certificate, given we do not want a
certificate based authentication (e.g. for relaying), most scenarios still
use username/password (via SASL).

Running "openssl s_client -connect mail.example.net:25 -starttls smtp" when
the SSL certificate is from a publically trusted root CA will lead now to an
incomplete certificate chain.

Why? The root CA bundle does not contain intermediate certificates, which is
correct. The lazy way is now to put the intermediate certificate simply into
/etc/pki/tls/certs/whatever-ca-intermediate.pem and run 'c_rehash'.

But running "openssl s_client -connect mail.example.net:25 -starttls smtp"
now again will show a certificate chain from the SSL certificate via the
intermediate certificate including the root CA - which isn't really perfect
either.

RFC 5246, § 7.4.2 [1] says "This is a sequence (chain) of certificates.  The
sender's certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it.  Because certificate 
validation requires that root keys be distributed independently, the self-
signed certificate that specifies the root certificate authority MAY be
omitted from the chain, under the assumption that the remote end must already
possess it in order to validate it in any case.". This is also how e.g.
Qualys SSL Labs handle their tests (delivering root CA in a chain leads to
a warning) and what e.g. the CA/B Forum meeting minutes 2014-06-17 [2] are
also discussing (avoid root CA in chains to keep them short).

So, various websites suggest to just feed the intermediate certificate into
confCACERT (+ /etc/pki/tls/certs/whatever-ca-intermediate.pem). While this
indeed works at the first glance (proper certificate chain for inbound SMTP
with STARTTLS), it breaks all outbound SSL certificate verifications, given
/etc/pki/tls/certs/ca-bundle.crt file is no longer referenced; verify=FAIL"
is now what is logged for each outbound SSL/TLS connection that is not using
the same parent CA like confCACERT contains.

Building an own bundle for confCACERT? Possible, but not really upgrade-safe
and/or requires manual (or scripted) handling afterwards.

Under the hood, sendmail uses SSL_CTX_use_certificate_file() from OpenSSL.
OpenSSL recommends that SSL_CTX_use_certificate_chain_file() is used instead
of SSL_CTX_use_certificate_file() [3]: "SSL_CTX_use_certificate_chain_file()
adds the first certificate found in the file to the certificate store. The
other certificates are added to the store of chain certificates using 
SSL_CTX_add1_chain_cert.".

This means, the above sendmail configuration snippet works as expected when
confSERVER_CERT contains both, the SSL certificate and the intermediate cert.
This is also how Apache's SSLCertificateFile works since >= 2.4.8 and this is
also what e.g. Let's Encrypt reference ACME client (certbot) but also other
ACME clients (e.g. dehydrated) are delivering by default.

How to enable SSL_CTX_use_certificate_chain_file() in sendmail? According to
sendmail/tls.c it's preprocessor option _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE.

[1] https://tools.ietf.org/html/rfc5246#section-7.4.2
[2] https://cabforum.org/2014/06/17/2014-06-16-17-18-minutes/
[3] https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_use_certificate_chain_file.html

Version-Release number of selected component (if applicable):
sendmail-8.15.2-25.fc28

How reproducible:
See above.

Actual results:
Intermediate certificate passed via confSERVER_CERT is ignored.

Expected results:
Intermediate certificate passed via confSERVER_CERT is handled properly.

Additional info:
Could you please clone this bug report for RHEL 8? I'm unfortunately not
allowed to do so (lack of bugzilla permissions).