sendmail STARTTLS doesnt work with Let'sEncrypt

If user@outlook.com replies, here is my server verification in the sendmail log file:
Code: 
May  1 14:49:08 mail sm-mta[10508]: STARTTLS=server, relay=mail-vi1eur05olkn2033.outbound.protection.outlook.com [40.92.90.33], version=TLSv1.2, verify=OK, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
 
My MUA is mail/mutt and my configuration file displays the "Authentication-Results:" headers like this:
Code: 
Authentication-Results: mail.example.com; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: mail.example.com; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: mail.example.com; dkim=pass (2048-bit key; unprotected) header.d=outlook.com header.i=@outlook.com
        header.b=iDRuR7J7
That way I can see if the email is sent from a legit sender.
 
What version of sendmail are you using? 8.16.1 or newer?

Do you have in the mc file: define(`confDANE')dnl ?

Is your dns resolver using dnssec?
 
hruodr said:
What version of sendmail are you using? 8.16.1 or newer?

Do you have in the mc file: define(`confDANE')dnl ?

Is your dns resolver using dnssec? I am using unbound, but do not know how to check it.
Click to expand...
Recently updated to 8.17.1 but was 8.16.? before and was working the same way.
I don't use DANE or DNSSEC for now. Perhaps later ;-)
 
PMc said:
Furthermore, You definitely also need this:
define(`confCACERT_PATH', `/etc/ssl/certs')dnl
Otherwise verification of your clients cannot succeed ("self signed cert encountered in tree"), because the actual CA root certs are nowhere in the live environment. (They are either in the system path /etc/ssl/certs or in the ca_root_nss.)
Click to expand...
I did it, and now I get: STARTTLS=client verify=OK

For server I did not test (my server rejects connections from outside due to blacklisting in zen.spamhaus.org)

Can I have many defines of confCACERT_PATH and confCACERT with different values?
 
facedebouc said:
For example an email sent to a user@outlook.com give "verify=OK" when connecting to the server:
Click to expand...
This does not mean much. The thing hits only when Let'sEncrypt is used on both sides.

But. interim somebody else reported to Let'sEncrypt as they were hit by the same issue - so now it's not only me hallucinating ;) , and we can be fairly certain that there is a bug.

The successful workaround is to use the option --preferred-chain "ISRG Root X1" when fetching the certificate. This will leave away the outdated intermediate cert.
 
hruodr said:
Can I have many defines of confCACERT_PATH and confCACERT with different values?
Click to expand...
Not in the same config/same sendmail process. You can copy the config and run another sendmail process, but for that to work properly you have to create a config with different pid-file, different stats-file (and probably an extra rc.d script).
And I don't see the use-case why You want to do this. You can put multiple certs in the confCACERT file (so even if you would use different authorities to sign your client and server certs, you could just cat them together), and confCACERT_PATH should be the one place where all the root cacerts are..
 
PMc said:
This does not mean much. The thing hits only when Let'sEncrypt is used on both sides.

But. interim somebody else reported to Let'sEncrypt as they were hit by the same issue - so now it's not only me hallucinating ;) , and we can be fairly certain that there is a bug.

The successful workaround is to use the option --preferred-chain "ISRG Root X1" when fetching the certificate. This will leave away the outdated intermediate cert.
Click to expand...
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
 
You must log in or register to reply here.
Back
Top