It's not easy to decide where I should ask a FreeBSD group or
sendmail one. I'm posting to both, but suggesting a follow-up-to comp.mail.sendmail.
I'm particularly interested---due to curiosity and my education on
the subject---in the following sendmail message in maillog:
--8<-------------------------------------------------------->8---
Nov 12 08:27:39 antartida sm-mta[72775]: STARTTLS=client, cert-subject=/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2, verifymsg=unable to get issuer certificate
--8<-------------------------------------------------------->8---
My intuition says the system doesn't have the certificate for the CN mx.google.com.
unable to get issuer certificate <--
cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2 <--
cert-issuer=/C=US/O=Google Trust Services/CN=WR2 <--
If my intuition is totally wrong, feel free to stop reading right here.
The hostname connecting to my sendmail that generated that line above is
aspmx.l.google.com
So I tried (as a guess) to connect to this host on port 25, saying
STARTTLS and fetching the certificates that came.
Because sendmail is my primary concern, I installed these certificates
in /etc/mail/certs. I was afraid that if they were outside of
/etc/mail, sendmail would refuse to read them. And if my operation
were not successful in this conservative approach, then it would be
a waste of time to try to move these cerficates outside of /etc/mail,
so I did not even try that because I did not succeed in avoiding the
message ``unable to get issuer certificate''.
I found got three certificates with the -showcerts option by OpenSSL.
They were GTS_Root_R1_2028.pem---this expires in 2028, but I already had
one for GTS Root R1 that expires in 2036---, GTS_WR2_RSA.pem and GTS_WR2_EC.pem.
I obtained them with
openssl s_client -connect aspmx.l.google.com:25 \
-starttls smtp \
-showcerts </dev/null
I obtained the hash of each certificate with, for example,
openssl x509 -noout -hash < GTS_Root_R1_2028.pem
Then I created the symbolic links using these hash as ls shows below.
But that did not change those log messages. I don't know how to
debug sendmail to the point of seeing which files it is reading.
Thanks for any advice you might have.
I think that you're probably on the correct track. I speculate that
it's a possible mismatch of where Sendmail is looking and where you have
your files.
# grep CACERT /usr/local/share/sendmail/cf/README
define(`confCACERT_PATH', `/etc/mail/certs/')
define(`confCACERT', `/etc/mail/certs/CA.cert.pem')
confCACERT_PATH CACertPath [undefined] Path to directory with confCACERT CACertFile [undefined] File containing at least
Note that CACertPath is for validating servers you connect to (STARTTLS=client), while CACertFile is for validating clients connecting
to you (STARTTLS=server).
Bjørn Mork wrote:
Note that CACertPath is for validating servers you connect to
(STARTTLS=client), while CACertFile is for validating clients connecting
to you (STARTTLS=server).
Please explain why you think this is the case. SSL_CTX_load_verify_locations(*tls_ctx, cacertfile, cacertpath)
is invoked in inittls() - for server and client side.
On 11/12/24 19:30, Wolfgang Agnes wrote:
It's not easy to decide where I should ask a FreeBSD group or
sendmail one. I'm posting to both, but suggesting a follow-up-to
comp.mail.sendmail.
I get why you chose comp.mail.sendmail. But my take on this is that
it's more of an OS (lack of certs) issue than it is a Sendmail (configuration) issue. But both work for me.
Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
writes:
Bjørn Mork wrote:
Note that CACertPath is for validating servers you connect to
(STARTTLS=client), while CACertFile is for validating clients connecting >>> to you (STARTTLS=server).
Please explain why you think this is the case.
SSL_CTX_load_verify_locations(*tls_ctx, cacertfile, cacertpath)
is invoked in inittls() - for server and client side.
Mainly based on experiments with all sorts of combinations. But looking
at the code also seems to confirm. The rest of that block is:
if ((r = SSL_CTX_load_verify_locations(*ctx, cacertfile,
cacertpath)) == 1)
{
# if !TLS_NO_RSA && MTA_RSA_TMP_CB
if (bitset(TLS_I_RSA_TMP, req))
SSL_CTX_set_tmp_rsa_callback(*ctx, tmp_rsa_key);
# endif
if (srv)
{
SSL_CTX_set_client_CA_list(*ctx,
SSL_load_client_CA_file(cacertfile));
}
}
But how are we supposed to configure a sendmail server then? MTA-STS...
means that the trusted CA list must include every public CA. Using the
can get a trusted client certificate, then "AUTH EXTERNAL" is pretty
much an open relay. What am I missing?
But how are we supposed to configure a sendmail server then? MTA-STS
means that the trusted CA list must include every public CA.
... then "AUTH EXTERNAL" is pretty much an open relay.
What am I missing?
MTA-STS has probably been "designed" by people who use http(s) for
everything - without considering the implications.
And just like SPF it breaks existing e-mail practices....
Yes, I have SRS working with Sendmail just fine. I found an old
`perlsrs' HACK years ago and have been using it ever sense. I drop the perlsrs.m4 file in the `/usr/share/sendmail/cf/hack' directory and add `HACK(`perlsrs')' to my mc file. It works well enough that I never have
Would you mind sharing this 'perlsrs' file? I can't seem to find it
and I'd like to take a look.
8--perlsrs-old.m4-->8--
8--perlsrs.m4-->8--
8--socketmap.m4-->8--
8--envfrom2srs.pl-->8--
8--srs2envto.pl-->8--
= $uid;$< = $uid;
8--socketmapd.0.31.pl-->8--
Pre-script: For some reason I don't see the post that Claus quoted,
so I'm replying to it here.
Bjørn Mork wrote:
But how are we supposed to configure a sendmail server then? MTA-STS
means that the trusted CA list must include every public CA.
I've been configuring Sendmail to use look in /etc/ssl/certs for
trusted CAs for years without any problem.
... then "AUTH EXTERNAL" is pretty much an open relay.
I think you're concerned about validated certs being the key to allow relay.
I have the following in my access(.db) file:
# Allow REDACTED to relay based on client TLS certificate.
CERTISSUER:/C=US/O=Let's+20Encrypt/CN=R3 SUBJECT
CERTSUBJECT:/CN=REDACTED_CN1 RELAY
CERTSUBJECT:/CN=REDACTED_CN2 RELAY
As the comment says and the `SUBJECT' value implies, certificates need
to be from the `CERTISSUER' *AND* have the proper `SUBJECT' listed on
in it's own `CERTSUBJECT' entry.
Only my servers are allowed to relay based on valid certificate *AND*
proper subject.
What am I missing?
I suspect that you want to look into `CERTISSUER' of `SUBJECT'
combined with `CERTSUBJECT' entries to have fine grained control over
who's allowed to relay based on certificates.
On 1/10/25 11:09, Claus Aßmann wrote:
MTA-STS has probably been "designed" by people who use http(s) for
everything - without considering the implications.
Where would you have had people publish MTA-STS information? I would
have preferred DNS, but I don't think that HTTPS is the worst thing in
the world.
BTW; how many versions are the _FFR build options supposed to stay before either being deprecated or made default?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 493 |
Nodes: | 16 (2 / 14) |
Uptime: | 34:53:16 |
Calls: | 9,740 |
Files: | 13,741 |
Messages: | 6,183,425 |