Everyone keeps saying "the connection seems to be fine", you included, so it seems there is something salient about that (fact?) that my ignoring is interfering with fixing the problem. I just don't see what it is.
Here is the syndrome:
- LE certs AS ISSUED by LE GIVE ERRORS and sendmail won't use them.
- By trial and error based on various ssl error messages:
first for sanity I renamed LE's files, as 0c 0fc 0k 0ch = cert fullchain privkey chain, and then determine that I have to MODIFY LE's keys:
Beyond that, I obtained the R3 cert as the cert of the top-level issuer.
KEY and CERT are what I tell sendmail to use, and I create them as follows (+ = concat) KEY = 0fc + R3 + 0k and CERT = 0c + 0fc.
- See the summary at end since I won't be able to build the example I intended {dammit}
Witness
define(confCACERT',
/etc/letsencrypt/archive/MAIL/CAC')dnl # <= EDIT cert (by now I forget what it contains.)
define(confSERVER_CERT',
/etc/letsencrypt/archive/MAIL/0c')dnl # <= EDIT
define(confSERVER_KEY',
/etc/letsencrypt/archive/MAIL/0k')dnl # <= EDIT
define(confCLIENT_CERT',
/etc/letsencrypt/archive/MAIL/0c')dnl # <= EDIT
define(confCLIENT_KEY',
/etc/letsencrypt/archive/MAIL/0k')dnl # <= EDIT
This is everyon's favorite setup, cert key cert key. Using THOSE data as LE provided.
make sendmail.cf
service sendmail restart
service sendmail restart
May 31 23:08:42 server sm-mta[616090]: NOQUEUE: stopping daemon, reason=signal
May 31 23:08:44 server su: (to smmsp) root on none
May 31 23:08:44 server su: pam_unix(su:session): session opened for user smmsp by (uid=0)
May 31 23:08:44 server systemd: pam_unix(systemd-user:session): session opened for user smmsp by (uid=0)
May 31 23:08:44 server su: pam_unix(su:session): session closed for user smmsp
May 31 23:08:44 server sm-mta[620051]: starting daemon (8.15.2): SMTP+queueing@00:10:00
May 31 23:08:44 server sm-mta[620051]: STARTTLS=server, Diffie-Hellman init, key=2048 bit (/)
May 31 23:08:44 server sm-mta[620051]: STARTTLS=server, init=1
May 31 23:08:44 server sm-mta[620051]: started as: /usr/sbin/sendmail-mta -Am -L sm-mta -bd -q10m
Ok, so no SSL complaints on INIT. BUT:
mailer says:
An error occurred while sending mail. The mail server responded:
5.7.0 Authentication required.
Please ensure that you are using the correct identity to send and that the used authentication method is correct. Verify that you are allowed to send via this SMTP server with your current credentials from your current network.
sendmail says:
May 31 23:11:16 server sm-mta[620115]: STARTTLS: x509 cert verify: depth=0 /CN=new.transbay.net, state=0, reason=unable to get certificate CRL
May 31 23:11:16 server sm-mta[620115]: STARTTLS: x509 cert verify: depth=1 /C=US/O=Let's Encrypt/CN=R3, state=0, reason=unable to get certificate CRL
May 31 23:11:16 server sm-mta[620115]: STARTTLS: x509 cert verify: depth=2 /O=Digital Signature Trust Co./CN=DST Root CA X3, state=0, reason=unable to get certificate CRL
May 31 23:11:16 server sm-mta[620115]: STARTTLS=server, relay=c-68-34-7-247.hsd1.mi.comcast.net [68.34.7.247], version=TLSv1.3, verify=NOT, cipher=TLS_AES_128_GCM_SHA256, bits=128/128
May 31 23:11:16 server sm-mta[620115]: STARTTLS=server, cert-subject=, cert-issuer=, verifymsg=ok
May 31 23:11:16 server sm-mta[620115]: AUTH warning: no mechanisms
My sendmail milter requires the sender of the message being sent to be authenticated, but it only logs success, not failure {laughs: so I should correct this decade-old oversight}, so that's why it's not saying "this mail is outta here because the sender is a ringer".
====================================================================================================================
Even here I have an unexpected result: these same (offered key and cert values) are now giving different errors than they used to: following this exact test (offered values === LE values) previously the complaint (I forget by now ...) was about missing values (signer cert, I think), that originally had me create keys based on some comment I ran across a couple days ago. An then, "All I changed between then and now," said the userland creature, "was to add this line
define(confCRL',
/etc/ssl/eAuuqRbQ')dnl # <= EDIT
to the MC file." where the eAu thing is " the CRL at http://x1.c.lencr.org/
" suggested by bruncsak above. [It's not working, as I am using it.]
The error seems to have "stabilized" as that CRL error, and /supposedly/ sendmail does not care about the CRL.
The bottom line (the QED I was striving for) is that sendmail is bailing on providing AUTH, and now from "a cause yet to be determined". Since it is NOT(?) the missing CRL that is the issue, this whole thread is irrelevant. {laughs}
===
Handsome as ever, I see. Banzai, etc.