For a fair while I have noticed that when one of my secondary mail servers (sentinel in this instance) delivers to my primary (shadow aka mail) the TLS verification fails [note STARTTLS=server]
But curiously, the secondary mail server log shows verification was OK [note STARTLS=client]:
So I went down the rabbit hole to figure out what was going on... after checking certificate validity and making sure all the roots were present and correct for validation I cranked up the sendmail logging and found this:
which led me to check my primary mail server's certificate:
An example of running that same command a few years ago (saved in my personal wiki when I setup TLS for sendmail because documentation often revives an aging memory
:
And then I found all the gory details here: https://www.ssltrust.com.au/blog/end-of-client-authentication-eku-in-tls-certificates
[Note: Sectigo is Let's Encrypt's upstream; LE removed client EKU in May 2025 for most, it just took me a while to go down the rabbit hole.]
Hopefully this saves someone else from going down this same rabbit hole for hours in future.
Code:
shadow sm-mta[87207]: STARTTLS=server, relay=sentinel.example.org [xxx.xx.xx.x], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256But curiously, the secondary mail server log shows verification was OK [note STARTLS=client]:
Code:
sentinel sm-mta[31065]: STARTTLS=client, relay=mail.example.org, version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256So I went down the rabbit hole to figure out what was going on... after checking certificate validity and making sure all the roots were present and correct for validation I cranked up the sendmail logging and found this:
Code:
shadow sm-mta[88140]: STARTTLS=server, cert-subject=/CN=sentinel.example.org, cert-issuer=/C=US/O=Let's+20Encrypt/CN=R12,
verfiymsg=unsuitable certificate purpose <<<<<<<<which led me to check my primary mail server's certificate:
Code:
openssl x509 -noout -purpose -in /etc/mail/certs/shadow.crt
Certificate purposes:
SSL client : No <<<<<<<
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : NoAn example of running that same command a few years ago (saved in my personal wiki when I setup TLS for sendmail because documentation often revives an aging memory
:
Code:
openssl x509 -noout -purpose -in /etc/mail/certs/shadow.crt
Certificate purposes:
SSL client : Yes <<<<<<<
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : NoAnd then I found all the gory details here: https://www.ssltrust.com.au/blog/end-of-client-authentication-eku-in-tls-certificates
[Note: Sectigo is Let's Encrypt's upstream; LE removed client EKU in May 2025 for most, it just took me a while to go down the rabbit hole.]
Hopefully this saves someone else from going down this same rabbit hole for hours in future.