Bug 253060

Summary:

sendmail submit is unable to verify certificate

Product:

Base System

Reporter:

Leo Bicknell <bicknell>

Component:

conf

Assignee:

freebsd-bugs (Nobody) <bugs>

Status:

New ---

Severity:

Affects Some People

CC:

bapt, bicknell, emaste, kevans, michael.osipov

Priority:

---

Version:

12.2-RELEASE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
diff -u with the exact proposed fix	none

Description Leo Bicknell 2021-01-28 12:47:08 UTC

If the user has configured SSL certificates for sendmail then when the sendmail submit service connects to localhost and receives the certificate it will be unable to verify that certificate.  Specifically the user will find a log message like this in their logs for every submitted e-mail:

STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

The fix is to add the following two lines to /etc/mail/freebsd.submit.mc:

define(`confCACERT_PATH',   `/etc/ssl/certs')dnl
define(`confCACERT',        `/etc/ssl/cert.pem')dnl

Then, assuming the user has a real certificate configured, they will get a message like this:

STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

This does not change any mail delivery behavior, sendmail does not care if the certificate is valid or not and does not alter behavior if it is or not.   This only changes logging, and would reduce admin confusion when an admin has configured a server cert.  

I believe this is safe to add to /etc/mail/freebsd.submit.mc for all users in the base distribution.

Comment 1 Leo Bicknell 2021-01-28 12:50:30 UTC

Created attachment 221990 [details]
diff -u with the exact proposed fix

Taken in /etc/mail on a FreeBSD 12.2-RELEASE system.

Comment 2 Michael Osipov 2021-07-08 12:09:23 UTC

I have just hit the same issue in a jail.

Sendmail is configured with a smart host (mail relay) company-internal, the mail server offers STARTTLS, sendmail follows and fails:
> Jul  8 14:02:46 deblndw013x3j sm-mta[88641]: STARTTLS=client, relay=mail2.siemens.de., version=TLSv1.2, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256

I have added company root and intermediate CA certificates to LOCALBASE and rehashed. As Leo desribed, both default values for CACERT and especially CACERT_PATH are unusable, the default config is unsuable.

Comment 3 Michael Osipov 2021-07-08 12:51:11 UTC

I have played around a bit what Leo has written.
The patch cannot be applied as such. If /etc/ssl/cert.pem does not exist sendmail will say:
> Jul  8 14:32:44 deblndw013x3j sm-mta[90513]: STARTTLS=client: file /etc/ssl/cert.pem unsafe: No such file or directory
> Jul  8 14:32:44 deblndw013x3j sm-mta[90513]: STARTTLS=client, error: load verify locs /etc/ssl/certs, /etc/ssl/cert.pem failed: 0
> Jul  8 14:32:44 deblndw013x3j sm-mta[90513]: STARTTLS=client, relay=mail2.siemens.de., version=TLSv1.2, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
Even if /etc/ssl/certs will contain valid hashed links.

Now if you consider to prepend a dnl because you don't have such a file it will fail also.
The only valid options I see are
* to leave confCACERT as-is and fix confCACERT_PATH only
* tell sendmail not to verify any paths and leave it to OpenSSL which will do the right thing. With that you can drop confCACERT if it does not exist
* apply libfetch's approach and set default's if neither is set:
https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/lib/libfetch/common.c#L1105-L1109

So this does work for me now:
> define(`confCACERT', `CERT_DIR/cacert.pem')dnl
> define(`confCACERT_PATH', `/etc/ssl/certs')dnl
output:
> Jul  8 14:51:27 deblndw013x3j sm-mta[90897]: STARTTLS=client, relay=mail3.siemens.de., version=TLSv1.2, verify=OK, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256

I prefer option 2 AND 3