My webserver had an application run the disk out of space, causing several errors, as one could imagine. One of the side affects has been the WACS.exe task running and being able to successfully renew the server's certificate.
I'm getting the "Failed Validation Limit" but not sure how long I have to wait before I can re-try the renewal process again.
I use Winacme in it's simplest method...one certificate; verification is served from memory via HTTP.
The link above or this one Description states
" All issuance requests are subject to a Failed Validationlimit of 5 failures per account, per hostname, per hour.
ANotWorking
ERROR
arcgis.lcwc911.us has an A (IPv4) record (66.216.164.13) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
A timeout was experienced while communicating with arcgis.lcwc911.us/66.216.164.13: Get "http://arcgis.lcwc911.us/.well-known/acme-challenge/letsdebug-test": context deadline exceeded
Trace:
@0ms: Making a request to http://arcgis.lcwc911.us/.well-known/acme-challenge/letsdebug-test (using initial IP 66.216.164.13)
@0ms: Dialing 66.216.164.13
@10000ms: Experienced error: context deadline exceeded
Yet from my location (Oregon, USA) I see with nmap
$ curl -Ii http://arcgis.lcwc911.us/.well-known/acme-challenge/sometestfile
HTTP/1.1 404 Not Found
Content-Length: 1245
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
X-Powered-By: ARR/3.0
Date: Wed, 15 May 2024 22:43:34 GMT
Thanks for clarifying that - I wasn't sure if it meant the counter would actually reset after 1 hour or not. I'll attempt using the Staging Environment.
I've cleared the issues on my server, so I'm going to make one attempt and go from there.
Just looked at my 4 other DMZ servers that use Let's Encrypt and they are all failing as well. It would indicate a firewall issue, but I haven't changed any rules for these servers.
I did read the above mentioned post, so maybe my geo-blocking is the culprit. Usually is since I don't really allow anyone in that's not from the US...anyway.
Authorizations today require the primary center (in the US) to succeed and at least 3 of the 4 secondary centers to succeed.
By blocking Singapore your auths cannot tolerate any (other) secondary failures. You are more vulnerable to failures due to temp comms problems anywhere in the path.
The locations and quorum are expected to change over time. Peter's excellent article covers this and provides best-practices as well.
Some firewalls have completely separate blade for geographic protection. My particular one does and it's very binary...accept / deny traffic from the country. After geo protection rules are passed, the actual security rules are traversed.
I guess I could dig into the geo protection settings and see if I have options to allow from a specific country on a specified port - port 80 in this situation. That said, call me lazy, but I have plenty of other work at the moment...I wear all the hats at my org and need to shift gears to setting up vm hosts. For now, I'll be setting a calendar reminder to see if the cert renewal task is completing in August.
I realize. At some point I'll have to address it, but for now, security trumps certs for my environment. If I can't find a way to allow port 80 for all geographies and this becomes a problem in the future, I'll need to move on to namecheap or something similar.
Again, I'm at the mercy of what configurations my FW will allow. Next week I'm going to research my firewall k-base and see if a way to do this exists. So far, I've found it very difficult to make any geo-protection exceptions. As I mentioned, it's very much an accept/drop traffic option for each country.
