IIS Validation of the required challenges did not complete successfully

I am using IIS and Certify th web the test is error free but request certificate generates the following error message:
Validation of the required challenges did not complete successfully. Invalid response from https://xxxx:443/.well-known/acme-challenge/R_Fjsvc2QhJ3FCRioRPYOtqSh368gDdSw-b7GwfHGVU []: "\r\n<html xmlns=“http”
A access from external to an text file in .well-known\acme-challenge\ works fine.
I have also modified the web.config that files without extension will be handled as text/plain.
What goes wrong?

Let’s Encrypt is saying the file’s contents are an HTML file… so your server is probably returning an error page, not a plain text file.

You can try https://letsdebug.net/ or let us know what the actual domain is so we can give you more insight.

If you are using the default configuration of Certify The Web you don’t need to modify an web.config files because during validation the http challenge response handler automatically sits in front of IIS and listens for domain validation requests (and answers them), so web.config files are only relevant if that process can’t happen.

When external validation attempts work locally but fail externally it’s usually because your public DNS points to the wrong server for that domain or DNS hasn’t updated yet. Another issue can be if you are using a loadbalancer or CDN/cloud proxy service in front of your server. I can’t test more without knowing your domain.

I see that IP is dynamic which suggest this might be a home server? If that’s the case you also have to make sure your server actually works externally. Try accessing your http site via your phone (mobile data, not your wifi) to check if you can connect and the correct server is responding, if you can’t connect then neither can Let’s Encrypt.

I tried Let's Debug and it was working without any problem, but Certify the Web is still not workung.
If I use the test buttom it works fine, but request Certificate not.
Yes I am using DynDNS, but I have a Mail server and a web-radio running without any problem.
I als used https://www.webpagetest.org/ to see if I can access to this sub-domain and I could read a text file in the root of this sub as well as in challenge dir.
I have other sub-dirs which are working fine, but this one I don’t get working CtW.

By sub-dirs do you mean sub domains? If so are they hosted on the same server that Certify is running on?

The response you’re getting back during validation has HTML in it, which proves the wrong (port 80 http) response is being sent either by your machine or something in between. The important point here is it’s your configuration that’s not working and that what you need to fix, the app itself works fine for hundreds of thousands of http validations per day and the chances of the issue being a bug in the app are close to zero.

If the test passes locally but the real request fails either the https challenge server process is failing to listen on port 80 (should work if you’re using IIS, won’t work if you’re using Apache/nginx etc because apache steals the port for itself), or your network configuration is incorrect and the external requests are not passing through the server that running Certify. The log file will say whether then http challenge response listener is working.

If you cannot use the built in (default) http handler you need to make sure Certify is creating the validation challenge response files in your website file system, if it’s doing this it will also create a file at /.well-known/acme-challenge/configcheck which you can find in your filesystem and request via http://yourdomain.com/.well-known/acme-challenge/configcheck

For ease of use I’d recommend you switch to DNS validation and use acme-dns (using the public service suggested by the UI) - this is where you will be prompted to create a one time CNAME for each domain/subdomain pointing to the acme-dns server, then automated renewals just update the acme-dns service instead of your DNS. Alternatively you can script your own add/delete of TXT records: https://docs.certifytheweb.com/docs/dns/validation#dns-scripting - the main benefits of DNS validation are that you can validate without Let’s Encrypt being able to get to your domains http service and you can request wildcard certs (*.domain.com).

Thanks for your answers.
Yes, it was an error. I mean sub-domains.
DNS-Validation I cannot use, because my domain hoster currently let the request not go to my server!

By the way, I am using Sophos UTM firewall now. But the problem already exists before I installed Sophos.

It may be a problem with port 80, because for security reasons it is automatically swiched to 443!
But I made additional test with
via https://www.webpagetest.org/ from external. In all cases I was able to read the content of the text files. You can verify it, too.
Why is Certify not able to read the files?
Which write right Certify required?
Can I check the Certify modifications on web.config?
Does Certify leave any file under Challenge?

Thanks for you help.

Certify technically can read the files. It’s Let’s Encrypt that is not able to. They have multiple servers around the world that will check the URL randomly. For this reason, your website must look the same no matter where in the world the client is connecting from. In your log file, where it says invalid response, it is Let’s Encrypt that is saying that. Certify is only displaying Let’s Encrypt’s message for you.

Let’s Encrypt is okay with port 80 redirecting to port 443 as long as it is done with HTTP headers. If it uses JavaScript or HTML meta tags, that won’t work. I’m confused, though… because your port 80 examples don’t redirect to 443 at all. Are you sure this is the same domain?

Certify will usually clean up old challenge files. It seems to leave behind a configcheck file, though.

I have uploaded a picture from a screenshoot. Maybe Sophos only redirect it to https:// internally. I cannot check it, because the external web site I use for testing don’t show it.
In IIS port 80 and 443 goes to the same physical path. There is no possibility the move it to different pathes, as long as I know.
Cold it be, that the responce from let’s encrypt is a stored one and not an actual one? Because I use it like it called, for testing some things and not always the folder is used!

Any idea how continue to analyse the problem?

Are you using this setting?

If you are, then your physical filesystem isn’t being used for challenges anyways. Certify would intercept certain URL paths that IIS could otherwise accept. This is a recommended option to use for IIS environments.

Let’s Encrypt will cache successful validation attempts and not require Certify to always respond to new ones. It should be obvious that failed attempts are not cached.

It sort of feels like you’ve over-complicated your setup and can’t figure out why it’s broken. I would suggest deleting your current setup in Certify, revert any web.config changes you’ve manually made and enable the checkbox above.

If you run into issues after re-creating the profile in Certify, post those logs.

1 Like

One thing that’s very relevant is that it’s Apache that’s replying to the example domains you’ve provided, not IIS. so either you’re running Apache (not IIS) or these validation requests are going to the wrong place.

You can use Apache with Certify but you need to set the website root folder properly in the UI, the http challenge server process won’t work and you have to use apache to answer the requests, and you have to configure apache to serve the validation responses. web.config’s don’t work in apache.

There is no Apache installed on my servers at all!

Its unbelievalbel, it is not the first time, that I deleted this certificate and set it up again.
But this time it was working. I deleted it again and added it to the certificate, where also the other sub-domains are included. And it was also working fine.
Something has changed, I guess. But I don’t know what.
By the way, I have not changed anything in the Renewal Settings. Challenge Server and as well Status Reports was and are still enabled.
Thanks everybody for your help!

1 Like

Great, well just so you know www.althoff-fam.de and test.althoff-fam.de are being served using Apache, running the TYPO3 content management system (php), so even if you’re not running Apache, whatever is hosting those domains is :slight_smile: