Certificate Renewal after ISP change

[mybadcode]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:capitolwire.com

I ran this command:

It produced this output:

My web server is (include version): IIS version 10

The operating system my web server runs on is (include version): Windows Server 2016

My hosting provider, if applicable, is: Comcast

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

nmap shows ports 80/443 open

Starting Nmap 7.91 ( https://nmap.org ) at 2023-05-02 09:39 Eastern Daylight Time

Nmap scan report for capitolwire.com (50.174.33.152)

Host is up (0.0031s latency).

rDNS record for 50.174.33.152: 50-174-33-152-static.hfc.comcastbusiness.net

PORT STATE SERVICE

80/tcp open http

443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 7.63 seconds

[MikeMcQ]

Welcome to the community @mybadcode

@mybadcode

My web server is (include version): IIS version 10

Are you sure your DNS is pointing to the new IP? Because I see IIS 8.5

curl -I https://capitolwire.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET

[mybadcode]

Sorry, you are correct it still is 8.5 Once we know we can resolve the renewal we will upgrade. It was working well until we changed providers.

Error we get
Authorize identifier capitolwire.com

Authorizing capitolwire.com using http-01 validation (SelfHosting)

{

"type": "urn:ietf:params:acme:error:connection",

"detail": "50.174.33.152: Fetching http://capitolwire.com/.well-known/acme-challenge/tvXrsmIZVHGjO7K7P2m9JSZ9n42UvI0m5

TqUgAPVQ0: Timeout during connect (likely firewall problem)",

"status": 400

Authorization result: invalid

[MikeMcQ]

It looks like you do have a firewall problem. See the let's debug test below. First test successfully reaches your domain but the test using the let's encrypt staging server is blocked by a firewall. This is almost always due to a firewall that is blocking certain IP addresses

Test result for capitolwire.com: Error

[Bruce5051]

Using this online tool https://check-host.net/ from various locations around the world yields Permanent link to this check report I see several "Connection timed out" results.
Looks like some kind of GeoLocation blocking.

And for those want to see it visually.

[mybadcode]

Thanks, we do have GeoLocation blocking countries. Is there a list of sites Let's Encrypt respond from so we can whitelist those countries (or IPs)

[Bruce5051]

@mybadcode

Is there a list of sites Let's Encrypt respond from

Short answer: NO.

Longer answer:
What IP addresses does Let’s Encrypt use to validate my web server?
Let’s Encrypt does not publish a list of IP addresses we use to validate,
and these IP addresses may change at any time.

Let's Encrypt uses Multi-Perspective Validation Improves Domain Validation Security - Let's Encrypt

[petercooperjr]

In order to do their job of proving that you in fact own that name as seen by everyone on the Internet, they need to check from everywhere on the Internet (or at least as close as they reasonably can).

Some people manage to convince their firewalls (and/or firewall administrators) to always allow through the /.well-known/acme-challenge requests, or to include scripting of opening up the firewall before a challenge request and closing it up again after, if they "can't" just open up port 80 for everyone.

Another approach you may be able to use if you can't open up the web servers is to use the DNS-01 challenge instead, assuming that 1) you can script the changes needed for DNS as part of automatic renewals, and 2) your DNS server is available everywhere on the Internet. (For some reason people are more likely to run a DNS server open to everyone than run a web server open to everyone.)