ERR_TLS_CERT_ALTNAME_INVALID again?

[Kubernetes]

Hi there,

I found the following messages in my mail log:

Jan 27 13:26:26 [INFO] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1] [core] hook=queue plugin=cloudron function=queue_inbound params="" retval=OK msg="Message Queued (1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1)"
Jan 27 13:26:26 [NOTICE] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1] [core] queue code=OK msg="Message Queued (1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1) (1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1)"
Jan 27 13:26:26 [NOTICE] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1] [core] disconnect ip=XX.XX.XX.XX rdns=XXX.de helo=XXX.de relay=N early=N esmtp=Y tls=Y pipe=Y errors=0 txns=1 rcpts=1/0/0 msgs=1/0/0 bytes=135775 lr="" time=6.721
Jan 27 13:26:26 [INFO] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1.1] [outbound] hook=get_mx plugin=cloudron function=get_mx params=ONEOFMYDOMAINS.COM retval=OK msg="{\"priority\":0,\"exchange\":\"127.0.0.1\",\"port\":2424,\"using_lmtp\":true}"
Jan 27 13:26:26 [INFO] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1.1] [outbound] secured verified=false cipher=TLS_AES_256_GCM_SHA384 version=TLSv1.3 error=ERR_TLS_CERT_ALTNAME_INVALID cn=*.CLOUDRONDOMAIN.DE organization="" issuer="Let's Encrypt" expires="Mar 21 12:12:23 2026 GMT" fingerprint=E9:3A:8F:4E:01:XXXXXXXXX:05:F0:C4:59:7B:12:36
Jan 27 13:26:27 [NOTICE] [1C07FE1F-BFFD-44A5-BE12-C4FBAF177077.1.1] [outbound] delivered file=1769516786845_1769516786845_0_66_zECH7t_77_0c956581fbfa domain=ONEOFMYDOMAINS.COM host=127.0.0.1 ip=127.0.0.1 port=2424 mode=LMTP tls=Y auth=N response="<SOMEONE@ONEOFMYDOMAINS.COM> iElcNfKueGnACQAAlsLRwg Saved" delay=0.174 fails=0 rcpts=1/0/0

My concerns are regarding Error ERR_TLS_CERT_ALTNAME_INVALID

cloudron-support --troubleshoot shows

root@cloudron-server:~# cloudron-support --troubleshoot
Vendor: Hetzner Product: vServer
Linux: 6.8.0-90-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: Intel Xeon Processor (Skylake, IBRS, no TSX)
BIOS NotSpecified  CPU @ 2.0GHz x 8
RAM: 15988572KB
Disk: /dev/sda1       118G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.17 is running
[OK]	Dashboard is reachable via domain name
[WARN]	Domain CLOUDRONDOMAIN.DE expiry check skipped because whois does not have this information

I found a very old Thread about this where claimed that it has been fixed.

Is there anything to worry about or fix?

[joseph]

Does this happen when the mail of ONEOFMYDOMAINS.COM and *.CLOUDRONDOMAIN.DE are hosted on the same Cloudron?

[Kubernetes]

Yes, it does.

[joseph]

@kubernetes you can ignore that warning.

If you are curious - for internal cross-domain mails, the mail service short circuits the delivery i.e the mail does not go out of the server and come back in. I guess it's a haraka bug that this being logged as an error. AFAIK, there is no TLS involved in internal mail delivery (@girish please confirm).

[joseph]

@kubernetes btw, you can take that fingerprint and resolve to domain name from the certificate transparency logs, so that should also be removed from your initial post.

[Kubernetes]

@joseph Thank you for your quick help and response!

[girish]

Right, the haraka log can be ignored. I think the IP and cert name don't match and thus the warning. It's not a problem since such mails don't leave the server.