Outbound SSL log entry: "error=ERR_TLS_CERT_ALTNAME_INVALID"

[d19dotca]

I was reviewing some mail logs on my server today and found this:

2020-10-26T23:45:45.000Z [INFO] [5DBEA39F-1F3F-47D4-9657-B2E73169F4EF.1.1] [outbound] secured verified=false cipher=TLS_AES_256_GCM_SHA384 version=TLSv1.3 error=ERR_TLS_CERT_ALTNAME_INVALID cn=mail.<domain> organization="" issuer="Let's Encrypt" expires="Jan 23 02:21:38 2021 GMT" fingerprint=79:81:76:C6:C4:21:FC:0D:23:B7:AB:CA:A9:42:D6:AB:6D:64:F0:2B

I don't recall seeing that error before. As best I can tell, everything is working though. I am raising it simply because I've made two changes recently in the past two weeks, and perhaps one of these triggered this issue? I'm curious if this is something that needs to be fixed or if it can be ignored.

The changes I made recently were:

• Changed mail subdomain from my.<domain> to mail.<domain>.
• Changed the DNS provider, resulting in new certificates being generated for the <domain>.

Any thoughts? Anything I need to do to fix this?

[nebulon]

Looks like the mail domain name change caused this and the certificate is somehow wrong. Can you see if you maybe just hit https://forum.cloudron.io/topic/3186/how-to-fix-email-certificate-issue-in-5-6/2?_=1603190711357 ?

[girish]

Do you see this many times (like for every mail being sent out?) or is just one log?

[d19dotca]

@girish I see it many times now that I look deeper into it. When I export the full raw logs for email, and search for "ERR_TLS_CERT_ALTNAME_INVALID", I see it finds it 393 times and that's just in just a one day period by the looks of it (26-27th).

@nebulon I will see if that fixes it, will report back soon.

[d19dotca]

More a note for myself... the time of this post is the time I followed and completed the instructions at https://forum.cloudron.io/topic/3186/how-to-fix-email-certificate-issue-in-5-6/2?_=1603190711357

I will watch and report back if I continue to see the error after this date/time of "Oct 27 10:54:31" in my logs.

[d19dotca]

@girish & @nebulon - It looks like it didn't fix it (the steps from the other page), as I still see it in the logs at 2020-10-27T18:06:51.000Z which is UTC and translates to 11:06:51 AM Pacific Time, well after I followed the earlier steps which was as of 10:54 AM Pacific.

[d19dotca]

Just an update... I still see this happening in the logs. Was about to make a post on it and realized I had this one from October 2020 already. haha.

Here's a latest log example:

Mar 09 16:43:59 [INFO] [35E59150-4AB6-4294-B369-B38CEECFAD88.1.1] [outbound] secured verified=false cipher=TLS_AES_256_GCM_SHA384 version=TLSv1.3 error=ERR_TLS_CERT_ALTNAME_INVALID cn=mail.<domain.tld> organization="" issuer="Let's Encrypt" expires="May 23 11:00:50 2021 GMT" fingerprint=<fingerprint>

Any ideas why this is still occurring? I'm using Wildcard DNS as the DNS type, if that matters at all. And I have the mail server changed from my.<domain.tld> to mail.<domain.tld> if that is relevant here too.

[girish]

@d19dotca do you get this even after restarting the mail server?

[d19dotca]

@girish Yes, I do. This is basically the same error I've seen since October when I reported it last year and the mail server has of course been restarted many times since then for updates and such, so it seems to still be sticking around.

[girish]

@d19dotca Ah, I see this on our server as well. It seems that this is printed for all incoming mails because Haraka tries to transfer mail to Dovecot via TLS (via LMTP). Disabling SSL removes the message. Since the message transfer is internal, it's fine. I have pushed the fix for next release but the message is safe to ignore.