Mail server sending to postfix refusing TLS connection with "certificate expired", but it's not

Well, then I'm, pretty sure I'm fine :smiley:

Thanks for the support!

4 Likes

Yeah, that's the theory.

In practice, I found this a few days ago, when I started to thoroughly look into that technology and built a test environment.

The problem with the "expired cert" arises only and specifcally when both sides use Let'sEncrypt certs.
And it arises with very new software.

What should happen to the mailserver? What is worrying You? :wink:

Technically we call this a false positive (or false negative, as you want it): the certificate is flagged as untrustworthy although it is trustworthy. So what can happen is, communication does fail, and you don't get your mail.

And then you start reading the sourcecode evilgrin

I did, I read the code of sendmail (it's beautiful), and the bug was not there.
Now I assume it is in openssl. Interesting that You say it suddenly appeared a few days ago. Then it could be a regression.
Could You figure out what exactly has been changed/upgraded at that time?

1 Like

That makes really little sense.

Are you sure the option we were talking about yesterday refers to the certificate chain and not to a root store?

1 Like

Screenshot_2022-05-01_18-26-59
No MX records that I can find.
:thinking:

3 Likes

It's just the fact.

I don't remember option. I do remember what is in the files:

Alice uses a Let'sEncrypt cert. Bob has the expired DST X3 caroot in his root store, and the DST intermediate in his(!) chain. Kabumm!

It doesn't matter what certificate Bob actually uses.

I assume this is a bug where the local chain-data for authentication spills over into the chain-data for verification, inside of openssl.
To me this makes a lot of sense, because it is quite typical for bugs that were fixed, but forgot a corner-case.

The option? Maybe you mean the --preferred-chain? That nice for automation, but technically doesn't matter much, because I can as well take an editor and delete the offending cross cert out of the chain-file. The effect is the same: as soon as Bob does not have the DST internediate in his chain-file, the error is gone.

I'm talking about this option:

"List of acceptable CAs" can mean "a root store" instead of "the certificate chain."

The hostname of the mailserver itself shouldn't have a MX RR, the MX RR is for the apex domain and should point to the mailservers hostname.

2 Likes

That's the interesting part: Nothing. Not on my mail server at least …

1 Like

Exactly. E.g. l3u.de has an MX record pointing to mail.l3u.de.

2 Likes

Unless you'd like to receive emails for foobarbaz@mail.l3u.de :stuck_out_tongue:

2 Likes

That's when the backup mechanism triggers. If no MX is found, the fqdn itself is assumed as MX and MTAs will try the A record.

1 Like

Sure, but it's better, I think, to do everything as best as possible. :slight_smile:

But a MX record for mail.l3u.de is probably unnecessary. :wink:

2 Likes

Yes, but... I do have mx, srv, spf, dmarc, and tlsa records for my MX. I use its own name for "technical" mailboxes, like dmarc and mta-sts reports, postmaster, etc.

2 Likes

Y'all know what the funny thing is?

My mailserver isn't using DST Root X3... For an entirely different reason: it's using the "experimental" E1-X2-X1 chain instead of R3-X1(-DST).

1 Like

You don't have a RSA certificate configured?

My servers are all "dualstack" with regard to RSA/ECDSA.

4 Likes

Including mail servers?

1 Like

Correct.

2 Likes

I do, that goes to DST right now. But nobody ever uses it.

I'll have to configure it to use GTS for RSA, I switched mail system from mailcow to mailu.

(And I don't have dual stack on http anymore, since transitioning from nginx to caddy)

2 Likes

Ah, thanks, I see. No, it definitely means the chain file here.

But I didn't fully understand this either. So I started to read the tls.c file of sendmail, and got some understanding of what they are doing.
Then I tried to do just the same with openssl s_client - and got the same error!

So, sendmail is out of the loop, and I suppose this can happen with any software for mutual auth that links openssl.

I think over time we will see more of these. Usually when people get that error, they would think, "bah, thats a really old client - it's their problem", and never mind. Only a small percentage comes up to here.

1 Like

But... SMTP isn't supposed to use mTLS. Or is it? It's the first time I hear about it.

I assumed it was just using server authentication like any https server.

1 Like