The problem is that since yesterday (10/10/2024) my certificate for the domain suddenly stopped automatically updating via win-acme v2.2.9.1.
Up until this point, everything worked fine and according to the logs, the certificate was updated automatically without any errors.
I tried to run a manual update via win-acme and got an error:
2024-10-11 19:39:31.261 +03:00 [DBG] Renewal period: 55 days
2024-10-11 19:39:31.264 +03:00 [VRB] Sending e-mails false
2024-10-11 19:39:31.288 +03:00 [INF] No command line arguments provided
2024-10-11 19:39:31.293 +03:00 [VRB] ExePath: C:\inetpub\letsencrypt\wacs.exe
2024-10-11 19:39:31.293 +03:00 [VRB] ResourcePath: C:\inetpub\letsencrypt\
2024-10-11 19:39:31.293 +03:00 [VRB] PluginPath: C:\inetpub\letsencrypt\
2024-10-11 19:39:31.305 +03:00 [INF] Software version 2.2.9.1701 (release, pluggable, standalone, 64-bit) started
2024-10-11 19:39:31.306 +03:00 [INF] Connecting to "https://acme-v02.api.letsencrypt.org/"...
2024-10-11 19:39:31.311 +03:00 [DBG] [HTTP] Send GET to "https://acme-v02.api.letsencrypt.org/directory"
2024-10-11 19:39:41.305 +03:00 [DBG] Connection failed: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
2024-10-11 19:39:41.305 +03:00 [DBG] [HTTP] Send GET to "https://acme-v02.api.letsencrypt.org/"
2024-10-11 19:39:51.300 +03:00 [DBG] Connection failed: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
2024-10-11 19:39:51.300 +03:00 [DBG] Initial connection failed, retrying with TLS 1.2 forced
2024-10-11 19:39:51.300 +03:00 [DBG] [HTTP] Send GET to "https://acme-v02.api.letsencrypt.org/directory"
2024-10-11 19:40:01.305 +03:00 [DBG] Connection failed: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
2024-10-11 19:40:01.306 +03:00 [DBG] [HTTP] Send GET to "https://acme-v02.api.letsencrypt.org/"
I tried to ping the address via cmd.exe and it cannot connect to the address, 4 packets were lost out of 4 attempts.
I checked to ping other hosts - and they pinged successfully.
I assume that my IP address 45.133.235.126 somehow got into your block list and now I cannot update my certificates. I ask for help to solve this problem. Thank you.
My domain is: 45.133.235.126 (hidden for security reason)
Have you changed your local network routing recently? Because the IPv4 address for acme-v02.api.letsencrypt.org is 172.65.32.248 (today).
There is a range of private IP addresses that start with 172. But, that should only be for the CIDR range 172.16.0.0/12.
If you setup your local network (wrongly) to use, say, 172.0.0.0/8 that declares a wider range of IP addresses as private. Your local network won't then route requests for these extra IP to the public internet. The acme-v02 IP is between /8 and /12 so you won't be able to reach it. See: IPv4 Private Address Space and Filtering - American Registry for Internet Numbers
I don't know Windows 2012 well enough to suggest specific tools to check your routing. I would if you were on a *nix system
It seems, WSL is like a docker system "for Windows".
So, it can run Ubuntu [as a VM].
Naturally, you can then run Linux commands within that Ubuntu VM.
But not natively from the Windows host system.
So...
Although it may provide what I was looking for, it's a whole lot to do for just that one command.
[not worth the effort]
That said, WSL has other upside/advantages [and also downside/disadvantages].
Win Server has Hyper-V.
Which can run any VM...
But that would still run commands outside the host [inside the VM].
Although, in this case, the path would be the same - so, the trace would be relevant.
Still... creating a VM just to run one command is very time expensive.
And... the Win Server would have to be installed as the host [not within a VM itself].
[not many systems allow child VMs to reshare their resources to grandchild VMs]
Thanks everyone for the answers.
When I open the URL acme-v02.api.letsencrypt.org via servers browser, the URL does not load.
If I connect a proxy-VPN on the server and try to open the URL acme-v02.api.letsencrypt.org via browser, it opens fine.
What could be the problem? I did not change any network routing settings before this problem. Maybe the hosting provider did this?
I attached the screenshoots with the commands tracert and traceroute bellow.
tracert acme-v02.api.letsencrypt.org
returns answer: Request timed out
traceroute -T -p 443 acme-v02.api.letsencrypt.org
returns answer: "traceroute" is not an internal or external cmd command
I tried to execute the curl command curl -I https://cloudflare.com, but it is not supported by Windows Server 2012 R2
When you test connection to the acme URL from a browser you must use HTTPS like https://acme-v02.api.letsencrypt.org/directory HTTP requests to that URL are expected to fail
If the traceroute doesn't even get past the first hop (typically your network's router), as is in your screenshot, you most likely have a broken network setup somewhere. Possibly a misconfigured routing table or firewall that's confusing the 172.16.0.0/12 block.
I attached scrrenshot wit the commands route print and powershell invoke-webrequest https://cloudflare.com/cdn-cgi/trace
And I also executed two curl commands: curl -I https://cloudflare.com
and curl -I https://acme-v02.api.letsencrypt.org/
It returns different answers.
Please look to attached screenshoots.
Are you certain you've properly configured the network on this system? 45. is a public IP block, but you're configuring a 24-bit subnet with .1 as the router. Are you sure you have control over an entire range of 254 public IPv4 addresses?
This forum does not allow new users to upload images (my first posts were edited by a moderator, allowing photos to be embedded, thanks to him for that)
I uploaded last photos with Curl and Route request here (remove the space before .com):
To execute the CURL from Windows Server 2012, I installed this soft: curl(dot)se/windows
I did not change anything in the network configuration. Everything worked fine until 10/10/2024. I will ask the hosting owner if they changed the network configuration.
