Every now and then Mail.app decides the certs of the mail subdomain are invalid for some reason, even though LE renews correctly. Port 993 seems to hang for some reason, anything worth investigating?
ApisCP version:
[root@~]# cpcmd misc:cp-version
revision: 3ec2e7884c258580fa707cfe827a4269861007c6
timestamp: 1730519492
ver_maj: 3
ver_min: 2
ver_patch: 45
ver_pre: ''
dirty: false
debug: false
Operating System:
[root@~]# uname -r
6.12.1-1.el8.elrepo.x86_64
What is the certificate expiration as reported by openssl?
Note that -servername apiscp.com is used for SNI identification, which should match the mail server name you’re using (mail.DOMAIN.COM).
If openssl reports the updated expiration, then it’s a local certificate cache - restarting Mail.app should release that certificate. If the old expiration is still reported, then check haproxy. It operates as a wrapper, so systemctl status haproxy will report when it was launched - not last reloaded. Check the process tree, e.g.
root 10496 0.0 0.0 44752 3176 ? Ss 2024 0:01 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -f /etc/haproxy/conf.d
haproxy 9729 0.0 0.0 67808 23052 ? S Jan14 0:00 \_ /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -f /etc/haproxy/conf.d -Ds -sf 22984
haproxy 9807 0.6 0.4 262340 160924 ? Ss Jan14 35:22 \_ /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -f /etc/haproxy/conf.d -Ds -sf 22984
I have seen this issue as well (although not in a couple months). It does seem like it’s some odd local cache where Mail.app randomly goes back to an old expired certificate (when I clicked “Show Certificate” I saw a cert that expired months earlier, not even one that “just” expired). I chalked it up to a bug in Mail.app… haven’t seen any issues with certs elsewhere.