I ran this command: Mozilla Thunderbird Get Messages
It produced this output: Thunderbird can send but not receive email on ports 993 or 995 with STARTTLS, and SSL/TLS opens the Security Exception popup and 'Get Certificate' returns 'Unknown Identity'.
My web server is (include version): OpenLiteSpeed 1.7.5
The operating system my web server runs on is (include version): Ubuntu 18.04.3
My hosting provider, if applicable, is: DigitalOcean
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
CyberPanel 2.3.1
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): acme latest version
The certificate for the subdomain seems to work ok via https and I've followed these instructions for dovecot/postfix to try to resolve.
@9peppe thanks for the test results. The browser says the https cert is verified by Let's Encrypt but I suppose the config for tcp can be different? I suspect there's a DNS issue somewhere.
mail.wpturbo.uk:Verify error:161.35.33.120: Invalid response from http://mail.wpturbo.uk/.well-known/acme-challenge/7n8gZoeKUhkJheUvydnxW7-TDqUQ3w2F5m2KfDmAamw: 404
The path /home/mail.wpturbo.uk/public_html/.well-known/acme-challenge/7n8gZoeKUhkJheUvydnxW7-TDqUQ3w2F5m2KfDmAamw existed but the url was loading from /home/wpturbo.uk/public_html/mail.wpturbo.uk/.
Once I changed the path and re-issued there was then a dns error for www.mail.wpturbo.uk, looks like it wants an A and an AAAA record for the www.mail.wpturbo.uk subdomain.
And for the love of God don't make anything that's not Certbot write in /etc/letsencrypt.
Of course you have to tell "postfix dovecot nginx apache2 ..." that the certificate is in /path/to/some/dir/ -- only reload the services you have. Don't install a second webserver because of my example.
@9peppe thank you for your helpful assistance. My earlier mistake in thinking the https://mail.wpturbo.uk/ was secure was due to cookies masking the certificates status, once cookies were cleared it was unsecure.
I'm only using acme.sh because that's what I believe Cyberpanel uses. I believe I've solved the issue by taking the certificate and private key that were generated by the issuance via the console command above and pasting them into the Add SSL section for the mail.wpturbo.uk sub-domain in CyberPanel. So I assume the issue was associated with how Cyberpanel was configuring the paths when clicking their 'Issue SSL' button for the mail sub-domain (worked fine for the root domain). I had checked the dovecot paths, so not sure what it was.
SSLLabs was giving a grade B because 'certificate chain is incomplete', however adding the intermediate certificate below the main certificate returned a grade A.