I figured it could be related to how I set up the subdomain
ben.companjen.name in my host’s DirectAdmin: not as a subdomain of companjen.name, but as a separate domain. The same goes for FreshRSS, which is on a different subdomain but its own DirectAdmin domain. With DNS pointing to the same server, it has worked for quite a while. I could request Let’s Encrypt certificates for all DirectAdmin domains, but I was thinking that having FreshRSS on the same server but using a different certificate was causing the issue.
$ openssl s_client -showcerts -servername ben.companjen.name -connect ben.companjen.name:443 CONNECTED(00000005) depth=0 CN = ben.companjen.name verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = ben.companjen.name verify error:num=21:unable to verify the first certificate verify return:1
Looking further, the certificate was indeed the issue, but not because it was a different subject name. The curl website on SSL certificate issues and workarounds provided the above command. It shows that the TLS certificate for ben.companjen.name cannot be verified because there is no certificate for its issuer, Let’s Encrypt Authority X3.
In Firefox I had no issue viewing this website or its certificate chains. Apple’s Keychain Access, however, called it untrusted – until I also loaded the certificate for companjen.name. It appears that both Firefox and Keychain Access use CA certificates from other sources to validate the incomplete certificate. But that is not the solution I can use for systems I don’t control – I need a complete certificate.
Going back to DirectAdmin and comparing all the settings on the SSL Certificates page for the domains that all use Let’s Encrypt, I suddenly noticed a link ‘Click Here to paste a CA Root Certificate‘. On that page is a checkbox ‘Use a CA Cert‘.
It was unchecked for ben.companjen.name, and checked for the other domains, although I don’t know why – I don’t remember unchecking it. Anyway: checking it and saving the page fixed the issue.