• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Let's Encrypt randomly fails to renew www or webmail subdomains

Ksech

Basic Pleskian
I have about 20 domains using free Let's Encrypt certificates that auto-renew.

Sometimes they renew just fine.

Other times, the domain will renew, but the webmail and/or www subdomains will not. The error shown says something about connection, possibly firewall.

The thing is - it's random! And when I manually reissue the certificate, it usually renews the domain, and the www and webmail subdomains just fine. Once or twice I've had to reissue 2 or 3 times because of the same connection/firewall error.

I DO have a some small Amazon ip address ranges blocked in my firewall - but would this explain why the domain renews but the www and/or webmail doesn't renew at the same time? Could Let's Encrypt be using different IPs to verify the domain and the www subdomain and the webmail subdomain? If I could be certain this is the issue, I guess I could remove those blocks from my firewall (but I would hate to - these ranges were added due to excessive abuse on my server!)

If I cannot resolve this another way, I'd be happy to just have some sort of method to check all the subdomains (the emails are NOT helpful.) I found a PowerShell script to check SSL expiration dates, but despite me entering subdomain urls in the script, it appears to be only checking the primary domain, which doesn't help me.

The only tool I've found in Plesk for checking SSL expiration dates is Advisor, and it just shows the expiration of the primary domain, with no clue that the www or webmail is not secured.

Any suggestions for a fix, or for a tool that will check the www and webmail subdomains?
 
but would this explain why the domain renews but the www and/or webmail doesn't renew at the same time?
No.
Normally, www. and webmail. are just alternate names in the certificate for domain.tld if you checked those boxes in plesk to also secure www and webmail.
So they renew as one or they don't at all.
Did you mess around with the domains yourself, e.g. manually configuring hosting for the www. and webmail. subdomains?

Next time this happens, examine the certificate. Is there anything listed under Certificate Subject Alt Name?
 
Thank you Mow. I will look at that if it happens again.

FWIW... I ended up unblocking the Amazon ips, and the next auto renewal went through without a hitch. I checked access logs, and saw that 2 of the ips used during validation (out of a total of about 6 or 8) had been blocked in my firewall.

So maybe it was firewall related. I'll just have to wait and see how the next few renewals work.

These ips were blocked because of attacks on my server from several ips within a small ( /20 or smaller) block, which is why I blocked these ranges. Amazon has a LOT of bad players on their servers, so if I start seeing attacks from these ranges again, I will likely block them again and try to find a different solution.
 
See a solution / workaround for this here: Change Log for Plesk Obsidian
It states:
To not exclude the www and/or webmail SANs when the issuance of a SAN certificate failed, add the following lines to the panel.ini file:

[ext-letsencrypt]
require-www-webmail-sans = true

The gist is that if there's some kind of failure with general renewal (such as a firewall block preventing access to one of the many Let's Encrypt servers as described above), Plesk would try excluding the www and webmail records to see if the cert will renew without the additional records (in case there's a missing www DNS record, for example). I can see how for some that would be preferable behaviour, though it's not for us.

The above panel.ini entry prevents that behaviour; presumably meaning that if there's a failure to renew, the next time it attempts renewal it will try renewing the cert with all domains in the SAN, including that www subdomain. This way if one or two of the Let's Encrypt servers are unreachable (due to firewall blocks or outages, or any other reason), when it finally does reach a server, it will renew the cert exactly as it was. The only downside is if the www or webmail records really were preventing it from working, it will prevent overall renewal of the cert.
 
Back
Top