MikeL's FreeBSD howto - STARTTLS

Possibly useful links in no particular order:
Other often asked questions about sendmail (sendmail.org/~ca)
DaemonPortOptions (sendmail.org/~gshapiro)
sendmail command line debugging options (colorado.edu/~lessem)
Configuring sendmail for starttls weldon whipple
You'll find a bunch of excellent tips on using openssl to crack open and to verify your certificate and the certificate chain at the following: Acquia: Verifying the validity of an SSL certificate
mxtoolbox.com checktls.com

[20240322]
In maillog, seeing "STARTTLS=client, error: PEM_read_bio_X509_CRL".
This is a revocation file problem. If you never bothered with this, you'll see "STARTTLS CRLFile missing" in the log. To fetch a revocation file, in the same dir as your other certs:
pkg wget install
wget http://www.cacert.org/revoke.crl
I'm renaming it to include today's date and where I got it from:
mv revoke.crl revoke-20240322-cacert.org.crl
Now test the file (you should see a bunch of lines about "Serial number" and "Revocation Date", ending with a block labeled Signature Value):
openssl crl -in revoke-20240322-cacert.org.crl -noout -text
Make sure this is in your .mc file as:
define(`confCRL', `revoke-20240322-cacert.org.crt')
Restart sendmail. Check maillog - this will show up immediately after restart.
Well, this didn't work, same problem. I tried converting it to pem/x509 as follows:
openssl crl -in revoke-20240322-cacert.org.crl -out revoke-20240322-cacert.org.pem
but that now gives "Unable to get certificate CRL". Fuck it, everything I've read says that CRL has been replaced with something called OCSP anyways, so I'm going to leave it with "CRFile missing".
BTW: Miracle magic incantation to check for yourself:
echo quit | openssl s_client -connect aspmx.l.google.com:25 -starttls smtp
Good detailed post on this stuff here

[20221223]
Minor note: my self-signed config does work without a CRL configured at all. In maillog (jump to end of log and search backwards for "stopping"), following "stopping daemon", there will be a line "starting daemon", followed by "STARTTLS: CRLFile missing", but STARTTLS does still work. I have since put the NetSol "OV" file here, and everything seems to be working. I've also put back my expensive NetSol wildcard certs, and that's working fine now...

Also note that this is working without the DAEMON_OPTIONS described below.

When building your self-signed cert, where it asks for your name or your FQDN, be sure to give it this servers actual FQDN as this is used by the cert verification. It must exactly match the server name, which I'm assuming came from a DNS lookup.


[20221222]
From today's messing around, I've learned that sendmail will not offer STARTTLS if it's unhappy with it in any way. I was worried that it wasn't being offered, as opposed to worried that there might be some minor config problem. I had to determine that it was compiled with it and such before I could worry about that other stuff. I was wrong, it was there.

sendmail -d0.10

sendmail -O LogLevel=14 -bs -Am
then enter STARTTLS
and check maillog for more info.
I had gotten it all working on a twin system with a self-signed cert. I ftped the self-signed over to this one and set this up to use the self-signed instead of my expensive NetSol cert. Everything suddenly started working, though obviously checktls shows a self-signed. I've tested the real cert extensively, it has integrity, so I'm confused. Maybe work on it some more tmw, at least I have a clue where to focus now.


[20211026]
Finally made the time to work on getting my wildcard certificate working.
In Apache: In sendmail:
[20200407]
Many years ago, when I started setting up this world, I set up a secondary server to do DNS and mail. This was BEFORE spamassassin. Over several years, I proceeded to build a sophisticated system to help reduce spam - I called it "the outhouse". It involved a "honey pot", and allowed customers to forward spam emails into it, it parsed headers, looked for URLs, it put forth bad guys info as an RBL, etc. Then spamassassin came along, and it was no longer worth maintaining this thing.

Anyways, something interesting that I learned, was that the spammers would favor my secondary MX server. As my spam control mechanism was all built on the primary, this caused me a problem. The secondary would accept the spam from the outside world, then try to relay it through the primary, and it would be rejected - the secondary is now stuck holding this stinker. So I just stopped using a secondary MX.

The reason to explain all this, is that now that I'm trying once again to have a secondary MX, I must finally get it working completely. I actually did have it mostly working for about a year now, but I never bothered with the details like STARTTLS, etc.

The issue here, is that to do this properly, you should have a commercial issued cert for this (the secondary), server. I'm not willing to spend hundreds of dollars each year just for this. The alternative is a self-signed cert. Bear in mind that the primary will use my commercial full-out cert, but the secondary will use a self-signed. Lastly, this will not do an authenticate verify, but the email itself will at least be passed encrypted.

openssl req -new -x509 -keyout brix-cakey.pem -out brix-cacert.pem -days 365
openssl req -nodes -new -x509 -keyout brix-sendmailkey.pem -out brix-sendmailcert.pem -days 365
openssl x509 -noout -text -in brix-sendmail.pem
define(`CERT_DIR', `/root/cert/localcert')
define(`confSERVER_CERT', `CERT_DIR/brix-sendmailcert.pem')
define(`confSERVER_KEY', `CERT_DIR/brix-sendmailkey.pem')
define(`confCLIENT_CERT', `CERT_DIR/brix-sendmailcert.pem')
define(`confCLIENT_KEY', `CERT_DIR/brix-sendmailkey.pem')
define(`confCACERT', `CERT_DIR/brix-cacert.pem')
define(`confCACERT_PATH', `CERT_DIR')
define(`confCRL', `CERT_DIR/sendmail.crl')
And of course test with checktls.com
You should expect "Certificate 1 of 1 in chain: Cert VALIDATION ERROR(S): self signed certificate So email is encrypted but the recipient domain is not verified" as the only error/warning.

Ok, now just to make things more confusing, I'm going to try a "free" cert. I really hope I don't regret this. The biggest issue is the damn things all expire every 90 days. And that's the long ones, comodo is only 30 days - what's the fucking use?


[20200526] - EVIL - do not do the following!
I just went to sslforfree to look into renewing and I find they've been bought out by some creep company and now all previous logins are gone, and it's now a paid service. Why is the internet so full of fucking assholes?

[20200407]
Went to sslforfree.com, and went through the machinations of generating a file, putting it in place on my web server, then having it generate a cert for me. Downloaded the cert files and installed them into cert dir. These went in straightforward, a key file used for both sendmail keys, a cert file for both sendmail certs, and a CA bundle.

The maillog is showing "unable to get issuer certificate", and a test email from me.com is showing a "verify=NO", yet CheckTLS.com is giving my a clean bill of health - don't know if I should worry or not. I'm gonna choose not to for now...

Hopefully I'll remember to report back in 90 days...
[20200331]
FYI re: TLS "verify=FAIL"
From https://weldon.whipple.org/sendmail/wwstarttls.html
10. What Appears in Logs and Headers? As STARTTLS-enabled mail servers communicate among themselves, it is almost certain (from my experience so far) that purchased certificates will fail to verify. ("verify=FAIL" will appear in the maillog.) If the server acting as a client doesn't offer a certificate, then "verify=NO" will appear in the mail log. (Clients acting as clients--which rarely have certificates at all--will also cause "verify=NO" to appear in the log.)
Something interesting to try here, is to search/grep for "verify=". In the same log where I'm seeing "reason=unable to get local issuer certificate", I'm seeing Ok. They're all the big guys, Google, Microsoft, Amazon, DigiCert, IsoMedia. Yet Earthlink and myregisteredsite are "OK". This makes me believe the error message is misleading - I assumed "local" meant ME. Thjis would indicate the error is on their end.
Never mind - I tried a checktls.com on a domain that gives a fail, but it passed just fine.

20191215 - Getting back to TLS issues.

Still seeing log entries like the following:
sendmail[78685]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
I've found an extremely useful test website: http://www.checktls.com/. Try full debug option for gory details. Note that the last thing shown pretty much matches what you'll see from the following openssl commands.

FYI: The above checktls website makes it clear that the email message is being encrypted, what's happening is that the verification of my domain name is failing.

openssl verify -CAfile AddTrustExternalCARoot.crt -untrusted 20170411-vncert-ov_chain.txt SECURE.VINTNERS.NET.crt

openssl s_client -starttls smtp -connect localhost:25

GOT IT!
Went back to NetSol website and looked carefully at the installation instructions, while reading between the lines. They describe several different filenames than the ones they provided me, which is why this never happened right over a year ago. There was no Apache_Plesk_install.txt file. So I followed their instructions, sort of by copying AddTrustExternalCARoot.crt to ca-bundle.com. I then went into my editor, and concatenated onto it OV_NetworkSolutionsOVServerCA2.crt, and then concatenated onto that, the OV_USERTrustRSACertificationAuthority.crt file. Then changed the .mc file confCACERT to CERT_DIR/ca-bundle.crt, remade the .cf file, and restarted sendmail.

Yay!


20190130 - Still struggling with STARTTLS


    Jan 30 18:07:00 pedicel sendmail[79818]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
I'm worried about the "verify=fail". I've tried changing the following line in .mc as follows, we'll see if this works. Explanation: it's trying to verify against my existing web cert which is for "secure.vintners.net", however sendmail thinks it's "pedicel.vintners.net" (which is the base system's name):
DAEMON_OPTIONS(`Port=smtps, Addr=pedicel.vintners.net, Name=TLSMTA')
To:
DAEMON_OPTIONS(`Port=smtps, Addr=secure.vintners.net, Name=TLSMTA')


I have a commercial cert from Network Solutions. This came with a zip file of the following files:
AddTrustExternalCARoot.crt
OV_NetworkSolutionsOVServerCA2.crt
OV_USERTrustRSACertificationAuthority.crt
SECURE.VINTNERS.NET.crt

I followed instructions to generate a key from this.
openssl req -newkey rsa:2048 -nodes -keyout secure.vintners.net.key -out secure.vintners.net.csr

I have installed saslv2 from pkg. Check with ps ax | grep sasl -- you'll see several occurances of saslauthd -a -pam.

Check that sendmail was compiled with sasl.
sendmail -d0.4 -bv root
Look for SASLv2 in the "Compiled with:" list.

Version 8.15.2
Compiled with: DNSMAP IPV6_FULL LOG MAP_REGEX MATCHGECOS MILTER
MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS
PICKY_HELO_CHECK PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS
USERDB XDEBUG
Canonical name: pedicel.vintners.net
UUCP nodename: pedicel.vintners.net
a.k.a.: [207.229.65.53]
a.k.a.: [192.168.7.1]
a.k.a.: [IPv6:0:0:0:0:0:0:0:1]
a.k.a.: localhost.my.domain
a.k.a.: [IPv6:fe80:0:0:0:0:0:0:1]
a.k.a.: [127.0.0.1]

============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = pedicel
(canonical domain name) $j = secure.vintners.net
(subdomain name) $m = vintners.net
(node name) $k = pedicel.vintners.net
========================================================

mike@vintners.net... deliverable: mailer esmtp, host gmail.com., user mikelempriere@gmail.com

Check that sendmail was compiled with STARTTLS, it should be in the same list as sasl above.

Check for proper cert installation, at a command line run:
sendmail -O LogLevel=14 -bs -Am
Then tail -n 50 /var/log/maillog and look for errors.
I'm seeing STARTTLS: CRLFile missing. Internet search says this a benign error that can be ignored, but I'm having problems so will try to fix this. Downloading from:
http://crl.cacert.org/revoke.crl (Note file is much longer than it thinks it is and download takes about 5 times the estimated)

I have this installed in a subdirectory under my root user's home directory. The groups and permissions are set appropriately. See below discussion of 20200326.


NOTE! Never mind -- this did not fix it.
My system has an extra ethernet port configured (it's builtin to the computer), so that I could plug my laptop straight into it for config work. (This is a co-lo'ed headless workstation.) In the LogLevel=14 output, I was seeing:
sendmail ... gethostbyaddr(nnn.nnn.nnn.nnn) failed: 1
I fixed this problem by changing the following in hostname.mc:
DAEMON_OPTIONS(`Port=smtp, Name=MTA')
to (IP addr being the one main IP that I do want used):
DAEMON_OPTIONS(`Port=smtp, Address=nnn.nnn.nnn.nnn, Name=MTA')
Do this also for:
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA')
Warning! If you do this, you must also specify localhost -- dup the same two lines above, but use Address=localhost.
Actually, that didn't fix it. What does fix it is to add to your .mc file:
define('confDONT_PROBE_INTERFACES`, 'True`)

[old]
Please note that 'make install' in /etc/mail does not work. Use:
make hostname.cf
then:
diff -cw hostname.cf sendmail.cf to check your changes.
then:
cp hostname.cf sendmail.cf to install it.
lastly:
restart-sendmail (this is my own script.)
Actually, looks like my sendmail-restart doesn't do it either -- do:
service sendmail stop
service sendmail start


To fix error STARTTLS=server, error: file /root/cert//secure.vintners.net.key unsafe followed by either Group readable file or Permission denied:
in your cert directory:
chmod 600 *.key
chown root *.key
[20200326] If you cannot do this, (perhaps you're sharing your certs with another non-email service, like ftpd)
Add other users that need access to the certificate to a single unix group. Simply edit /etc/group and add each username, seperated by a comma and no space, to the group you'll use for access.
Then chgrp [group used] all the files you'll be accessing in that dir
and chmod 640 files
Lastly make sure the dir they're in is also accessible:
chgrp . [group used]
chmod 750 .
Lastly, you'll need to disable this checking in sendmail with:
define(`confDONT_BLAME_SENDMAIL', ``GroupReadableKeyFile'') in your .mc file.


From article at: http://orcorc.blogspot.com/2010/04/
This article goes through a bunch of stuff with something called 'chkconfig' which I don't have, but that's ok, it's just checking that you've got saslauthd running. Just do:
ps ax | grep sasl
and look for saslauthd running. I'm currently showing four of them, I guess that's normal?
Openssl app has a nifty builtin tester - try the following:
openssl s_client -connect localhost:25
[20200325] additional possibly useful tests:
openssl verify chain.pem
openssl verify -CAfile chain.pem cert.pem

Copyright © 1995-2024 Mike Lempriere (running on host bayanus)