Test is success but renewal failure

the renewal of an IIS site (subsite.mydomain.be) on my W2016 server started failing after some time… The test with the certify.UI and Letsdebug gives no errors but a renewal of the certificate fails. The error gives a unauthorized error on the RDS-site of the domain (on another server). I’m not an expert in this…

2020-11-24 09:22:39.381 +01:00 [INF] Checking URL is accessible: http://subsite.mydomain.be/.well-known/acme-challenge/lRlrZ-Z066qVrBVxLNL1AOqEsyXej3KK7vKvo2lXM-k [proxyAPI: True, timeout: 5000ms]

2020-11-24 09:22:44.106 +01:00 [INF] URL is accessible. Check passed.

2020-11-24 09:22:44.107 +01:00 [INF] Requesting Validation: mydomain.be

2020-11-24 09:22:44.133 +01:00 [INF] Attempting Challenge Response Validation for Domain: mydomain.be

2020-11-24 09:22:44.133 +01:00 [INF] Registering and Validating mydomain.be

2020-11-24 09:22:44.133 +01:00 [INF] Checking automated challenge response for Domain: mydomain.be

2020-11-24 09:22:51.908 +01:00 [INF] Invalid response from https://remote.mydomain.be/RDWeb/Pages/en-US/login.aspx?ReturnUrl=/RDWeb/Pages/en-US/Default.aspx: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<?xml-stylesheet type=\"text/xsl\" href=\"../Site.xsl\"?>\r\n<?xml-stylesheet type=“text/css” "

Hi, so Certify has a built in http challenge service which bypasses IIS, and if that is unavailable for some reason then the http validation request gets answered by IIS instead. If you then have a default redirection to a particular page then the /.well-known/acme-challenge/ requests may get redirected before it is answered. In your case it’s redirecting unauthenticated users to the login page.

Check you are on the latest version of Certify - that’s important so we can see if the challenge server is running or not in the logs. Also check if the http challenge server is enabled under Settings in the app, I’ve heard of at least once case recently where it wasn’t.

If you are already on the latest version and the request is still failing you could try a reboot. Ensure that in the log file it says something along the lines of ‘http challenge service available’.

If you have purchased a license key you can log a helpdesk ticket by emailing support at certifytheweb.com with further details and your log file so we can help more.

We are thinking of implementing Certify the Web on our production servers. Many of our sites have secure redirects such as https://www.joe.com to https://www.joe.org. Will renewing the https://www.joe.com be an issue with the redirect happening before the /.well-known/acem-challenge/ page can be accessed during certificate renewal?

You mention having the latest version, does having the latest version installed allow for the challenge for a redirect site?

Let’s Encrypt (etc) will follow http > to https redirects during validation, the main thing is that whatever eventually does respond knows to serve the correct challenge response content.

Certify will by default spin up it’s own temporary http challenge server process which listens for the http:///well-known/acme-challenge/ requests. This sits in front of IIS in the http.sys pipeline so that IIS doesn’t need to be involved in the http challenge at all and normal traffic to IIS is not interrupted (they share the pipeline, which is a feature unique to windows and http.sys). This process then shuts down after domain validation has completed.

The comment regarding the “latest version” here was just because extra log messages had been added to help. In general though you should always use the latest version of Certify The Web and actively update the app on a regular basis (the UI will try to check for updates and let you know if one is available).