ERR_TLS_CERT_ALTNAME_INVALID again?
-
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/0My 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 informationI found a very old Thread about this where claimed that it has been fixed.
Is there anything to worry about or fix?
-
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/0My 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 informationI found a very old Thread about this where claimed that it has been fixed.
Is there anything to worry about or fix?
-
Yes, it does.
-
@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).
-
@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.