First of all, I am well aware of several existing topics with similar titles on this forum. Unfortunately, the solutions presented there do not apply to me.
I am trying to renew (via http-01) the certificates for a couple of sites that my IIS 8.5 (Windows Server 2012 R2 VM on Azure) is hosting.
The IIS is hosting a dozen sites on different domains, but only a handful refuse to be renewed. So this is not a problem with port configuration, or IIS configuration (?), or the like, it seems.
The essence of the problem is that some of the sites renew just fine with (licensed) Certify Certificate Manager 6.0.12.0, while others fail with:
I have observed the validation JSON file and the web.config being created successfully in the .well-known/acme-challenge directory of the failing sites, but the file is apparently inaccessible from the outside.
The Firewall is configured to allow http requests (obviously, since the other sites do work).
Once again, the same IIS is hosting other websites, they are accessible and have no problems renewing their certificates. The problem happens with only a handful of websites whose configuration on IIS is - as far as I can tell - identical to the others that do work.
I would appreciate any and all ideas of what could be wrong.
Licensed customers should email support {at} certifytheweb.com to log a support ticket, that way you don’t have to ask support questions on the community forum but redact useful information like the domains that do and don’t work.
I would first update your app to the latest version, because it make include a relevant fix, but it will also restart any related processes which could also help. I would suspect that the sites that are working have previously cached validation with Let’s Encrypt and so they are not being asked to fully complete http challenges.
IIS is only used for http challenge response as a fallback, the primary way the app responds to http challenges is through it’s own built in http challenge server which runs temporarily during validation. This process can be affected by some anti-virus products which have heuristics that dislike the process registering a http.sys listener, we are seeing this more frequently recently which suggests that some products share that heuristic in their databases. This may or may not be the problem, but start by updating the app.
The other possibility is that there is some difference for those domains (e.g. an IPv6 record etc) but we’d need to know the real domains to diagnose that.
For those, who encounter this problem and are wondering how I resolved it: It was an IP address mixup.
Chris from support pointed out a discrepancy in IP addresses among the sites I was having problems with versus those that renewed correctly and that led me to checking all the IP address mappings wholesale and discovered that some domains were not mapped properly after the Azure Virtual Machine migration earlier this year.
Turns out that the public IP address that is actually exposed by an Azure virtual machine is not necessarily what appears on the portal’s page for that machine. There is also public IP addresses product page that needs to be checked.
After fixing the IP addresses the domains were pointing to, I was able to renew the certificates for all sites.