Reading Time: 2 minutes
My websites and apps are behind the Cloudflare firewall. I use the web application firewall (WAF) to block anything and everything that shouldn’t be coming through. One periodic request was the quarterly re-issuance of Let’s Encrypt SSL certificates. These are a free way to secure your internet connections but it was a bit fiddly to get through my WAF rules. Here’s how I described my resolution of this in the past. But this morning, AutoSSL (a function with website hosting CPanel’s) started sending me errors. Once more unto the breach.
I struggle with AutoSSL and that is probably a reflection of my knowledge, which reaches as far as my personal experience. I struggle sometimes to understand what the error means. In this case, I was able to pick out that the AutoSSL app was getting a security error (403) and it was getting the error trying to access /.well-known. It suggests that this could be a website or DNS configuration error, but it’s neither.
It’s Cloudflare and my web application firewall rules.
Cloudflare and SSL Certificates
One thing I like about Cloudflare is that it sends you warnings that a certificate has been issued. This is a setting under the SSL/TLS Edge Certificates setting in the free Cloudflare account. If the AutoSSL runs, you won’t necessarily know unless you log into your CPanel and see. These announcements allow you to just know that it’s happened.
Cloudflare issues one when it creates its primary certificate is issued:
Log date: 2024-08-18 15:31:49 UTC
Issuer: CN=AE1,O=Google Trust Services,C=US
Validity: 2024-08-18 14:31:48 UTC - 2024-10-02 14:31:47 UTC
And then another notification when the backup Let’s Encrypt certificate is issued.
Log date: 2024-09-14 10:30:23 UTC
Issuer: CN=R10,O=Let's Encrypt,C=US
Validity: 2024-09-14 09:31:53 UTC - 2024-12-13 09:31:52 UTC
So when I got the error from AutoSSL, I wondered where the error was. I remembered that Cloudflare was making changes to its certification issuance process, and that it was happening this September. The changes were based on Let’s Encrypt’s own changes.
That’s the trap with technology, isn’t it? Two things happening at the same time. Are they related? Maybe?
Editing the WAF Rules
I have a rule that blocks access to a bunch of underlying website resources. For a long time, I tried to manage access by blocking countries and IP addresses and so on. But it’s so much easier to block access to the resource to everyone. Least privilege, right?
In any event, I use a Cloudflare web application firewall rule to limit access to my WordPress and other applications’ administrative and login functions. I wrote about limiting logins but using WAF rather than a WordPress plugin has meant that I don’t get any logins to limit.
The last time this happened, I added in the user_agent for Let’s Encrypt to allow it to bypass the rule. But that was not working based on the AutoSSL error. So I looked at the Cloudflare WAF events log and saw that my website host had been blocked at the time that the AutoSSL had attempted the certificate renewal.
Easy enough to solve that issue. I added the AS Number for my website host to the rule (see the bold line below).
(not ip.src in { [ip ranges] }) and
(not http.user_agent contains "Let's Encrypt") and
(not ip.geoip.asnum in { [ASNumber] }) and
(
(http.request.uri.path contains "wp-login.php") or
(http.request.uri.path contains "/wp-admin/") or
(http.request.uri.path contains "/login") or
(http.request.uri.path contains "/admin") or
(http.request.uri.path contains "/install.php") or
(http.request.full_uri contains "cpanel.ofaolain.com") or
...)
That was enough. I accessed my CPanel and the AutoSSL app and initiated another issuance sequence. This worked and all of my certificates were updated.
I don’t tinker a ton with my WAF rules so I’m not really sure, still, why this happened. I have, in the past, placed a block on the underlying resource (./well-known) but do not currently have a rule blocking it. I was glad that it was so easy to resolve.