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

You don't have a RSA certificate configured?

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


Including mail servers?

1 Like



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)


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

That's exactly what I read in the docs, a long time ago. Then I tried to do it that way - the A record should be able to receive mail - and it didn't work! Not for everybody.

Some software out there will deliver to MX records only.

But this is possible:

$ host -t mx mail is handled by 10

No, it does probably not do mTLS, but it does mutually authenticate both parties!
When you send a mail to a mailserver, you have

  1. verify=OK in the mail-log on your client (meaning, the server is who they claim they are), and
  2. verify=OK in the mail-log on the server (meaning, the client is who they claim they are).

Action 1 is the same as we do it with webservers. Action 2 is important, because on that result the client may be allowed to send relaying mail. Think of blocking spam senders: only clients that we know, and that can identify themselves, should be allowed to relay mail out to the world.

Yes, but that's what SPF and DKIM are for.

  • are you authorized to send mail for this domain? (SPF)
  • does this mail you're forwarding actually come from that domain? (DKIM)

Probably - but these are not so much fun. They are rather for the business people. :wink:

I will at next look into DNSSEC and see that I get my records moved from the registrar's DNS to my own. And then I'll see what can be done with DANE.
That DKIM stuff may then drop in as a corollary.

This here is basically a hunting party - I can do all the things that should be done in regular business, but I can do them properly and thoroughly, because no business needs are pressing me, and can find all the nasty bugs that still hide somewhere and hunt them down. :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.