|Summary:||sendmail submit is unable to verify certificate|
|Product:||Base System||Reporter:||Leo Bicknell <bicknell>|
|Component:||conf||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Some People||CC:||bapt, bicknell, kevans, michael.osipov|
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: 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: STARTTLS=client: file /etc/ssl/cert.pem unsafe: No such file or directory > Jul 8 14:32:44 deblndw013x3j sm-mta: STARTTLS=client, error: load verify locs /etc/ssl/certs, /etc/ssl/cert.pem failed: 0 > Jul 8 14:32:44 deblndw013x3j sm-mta: 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: 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