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

[Osiris]

@9peppe

it's using the "experimental" E1-X2-X1 chain instead of R3-X1(-DST).

You don't have a RSA certificate configured?

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

[rg305]

@Osiris

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

Including mail servers?

[Osiris]

Correct.

[9peppe]

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)

[PMc]

@9peppe

I'm talking about this option:

@PMc

the key is the key, the cert is the cert, and the cacert.pem is the chain, i.e. the collection of intermediate certificates that are needed for the adversary to get to one of their known root ca certs, which obviousely must be sent to the adversary during handshake.

But here the doc talks about something different: it appears to say that the cacert.pem contains a "list of acceptable CAs".

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

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.

[9peppe]

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.

[PMc]

@9peppe

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.

laugh
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 daemon.contact 
daemon.contact mail is handled by 10 daemon.contact.

[PMc]

@9peppe

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.

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.

[9peppe]

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)

[PMc]

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

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.