Hi,
I moved a hestia server to a new hosting provider. Basically installed hestia, and then did v-backup-user on the source and v-restore-user on the target. Then changed the DNS accordingly.
Most of the domains were OK, but one of them gave me the above error when trying to renew. I have seen several other posts on this topic, but in my case there was a different solution.
In this case the mail.domain.com record was pointing direct to the server IP, and the webmail.domain.com record was proxied at Cloudflare.
First thing I tried was to rebuild the mail domain.
Next I tried to remove SSL from the mail domain and re-add it in Hestia web UI.
Both of these have solved problems in the past but in this case the problem remained.
Finally, I was digging around in Cloudflare settings and saw that under SSL, and noticed this setting.
SSL/TLS encryption: Current encryption mode:Flexible
I changed it from Flexible to Full, and the SSL cert immediately renewed, first try.
You should never use that mode. It is inherently insecure and often breaks things.
This is fine temporarily (and only temporarily) when you need to renew an expired certificate.
This is the only Cloudflare encryption mode that is suitable for continuous use (unless you have an Enterprise plan). All of the lower Cloudflare encryption modes have increasing security issues the lower you go.
I did not turn on Flexible mode. I don’t know how it was activated. I did note that a lot of domains in that account showed that SSL settings were changed 2 months ago. Curious, as the client would never fiddle with those settings.
I have also had problems with Full (strict) in the past, so tend to leave it on Full personally.
The Full setting will allow connections to invalid certificates. This puts your site at unnecessary risk. You should learn how to fix whatever problems are affecting Full (strict) rather then making your site less secure with Full.
Would you stop locking your door because the lock sticks or would you fix it?
If you use rhe Always Use HTTPS setting, that can interfere with ACME HTTP-01 challenges. It is better to use your own HTTPS redirection that exempts the /.well-known/acme-challenge path.
@linkp Would you be so kind to share your current configurations in Cloudflare? The one that you shared before in this post is not available anymore. I’m on a free plan, use SSL Strict and did setup a page rule and Waf skip but can’t get the Let’s Encrypt renewal to work properly.
In the waf event reports I do see that the challenge is being skipped…
If you have any thoughts on this I would appreciate to hear about it.
Thanks in advance!
I moved away from Page Rules for ACME challenge configs in Cloudflare. I use the Configuration and Cache Rules now. I don’t make any specific WAF changes, only the following:
Configuration Rules:
Name: ACME Challenge
Expression: (starts_with(http.request.uri.path, "/.well-known/acme-challenge/"))
Automatic HTTPS Rewrites: Off
Browser Integrity Check: Off
Opportunistic Encryption: Off
Security Level Essentially Off
SSL: Off
It looks like you are confusing the expression that belongs in the expression editor with a pattern to be matched. Try using the expression editor along with the expression in my example.
One other non-intuitive thing is in the Configuration Rule: everything would appear to be off by default, so someone might wonder what there’s to do, but each of the ones you mentioned must be “added” despite the apparent default state.
Anyway, I hope this solves what appears to be a very recent problem, at least for us.
