TLS Handshake Failure: "Invalid Peer Certificate: NotValidForName" during Email Relay Session

get-help
1

I’ve been troubleshooting an issue with one of our email relay systems using our egress pool “rotation,” where we attempt to send emails to a remote server mail.exampleserver.com via STARTTLS. I’m encountering an error during the TLS handshake: invalid peer certificate: NotValidForName. Below, I’ll provide detailed logs, an analysis of the problem, and steps I’ve taken so far to diagnose and attempt to fix the issue. Any suggestions or insights you might have would be greatly appreciated.

[a3c1d21d-e9a0-4c48-916b-82b4975d0def]   0ns === conn_meta mx_plan={"Addresses":[{"addr":"10.0.0.0","name":"mail.exampleserver.com"}]}
[a3c1d21d-e9a0-4c48-916b-82b4975d0def]   0ns === conn_meta ready_queue_name="ip-2->exampleserver.com@smtp_client"
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 103µs === INFO: Attempting connection to ResolvedAddress { name: "mail.exampleserver.com", addr: 10.0.0.0 } port 25
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 312ms === INFO: DANE is not enabled for this path
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 318ms === INFO: MTA-STS resolve error for exampleserver: TXT record is not an STSv1 record
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 318ms ->  STARTTLS
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 422ms  <- 220 2.0.0 Ready to start TLS
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 529ms === INFO: STARTTLS handshake failed: "invalid peer certificate: NotValidForName"
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 529ms ->  QUIT
[a3c1d21d-e9a0-4c48-916b-82b4975d0def] 633ms === Closed
[a3c1d21d-e9a0-4c48-916b-82b4975d0def]   0ns === ERROR: TLS handshake with ResolvedAddress { name: "mail.exampleserver.com", addr: 10.0.0.0 }:25 failed: invalid peer certificate: NotValidForName
3

NotValidForName means that the server’s certificate does not match its hostname and cannot be trusted.

4

Hey @free-spirited-yorksh , I’ve been getting the NotValidForName error for many of my recipients. My setup is pretty secure, but it seems like the server’s certificate doesn’t match its hostname, causing this issue.

Since my configuration involves extra layers of security, what steps should I take to resolve this? Is it something on my end that I need to adjust, or do I need to reach out to the recipients to update their certificates or hostnames?

5

The odds of those recipients correcting their TLS setup is likely very low.

6

For those receiving domains, you can add configuration in the shaping file:

enable_tls = "Disabled"```
7

Unfortunately, we are seeing more of these and as Mike said, getting receivers to fix their certificates is not hopeful.

8

Thank you for your guidance on configuring the shaping file for handling receiving domains.

Given that we are dealing with multiple recipients and are encountering frequent transient failures, could you please advise on the best approach to manage these scenarios? Specifically, if some recipients consistently show transient failures, how can we configure our system to permanently reject and bounce these addresses to prevent them from remaining in our queue for extended periods?

Your assistance with this matter would be greatly appreciated.

9

We have a rewrite function you could use for that.

That will immediately turn a 4xx into a 5xx.
You could potentially make it conditional based on numer of retries as well:
and msg:num_attempts() >= 2

10

Theoretically, you could just add a bit of automation in your shaping file to catch these, but it could be dangerous if you are not careful with it and don’t monitor it.
Our default shaping config already does something like this, but it responds to a very specific regex:

regex="KumoMTA internal: failed to connect to any candidate hosts: All failures are related to OpportunisticInsecure STARTTLS. Consider setting enable_tls=Disabled for this site"
action = {SetConfig={name="enable_tls", value="Disabled"}}
duration = "30 days"```

Setting this to trip on "NotValidForName" could have unintended results or catch false positives if there is a temporary problem with a certificate.
11

If you are interested in some paid consulting work were we can dive into this in more detail, consider booking that here:
https://cal.com/team/kumomta/paid-support-session