Letsencrypt isn't your Letsencrypt client. A Letsencrypt client is a program that uses the ACME-protocol to communicate with Letsencrypt.
Then this is the problem.
Select another client:
Letsencrypt isn't your Letsencrypt client. A Letsencrypt client is a program that uses the ACME-protocol to communicate with Letsencrypt.
Then this is the problem.
Select another client:
I just tried two requests from (both from an external url, entered into chrome browser):
http://remote.hobel.at/.well-known/acme-challenge/ZkJmGhvErSoivpgoFVe1uHtcvYt41wsBMxg0djbfqoQ
Returns: “Hello !!” -> the content of the file
-> gets an HTTP-400 when trying to get the same url
For the first request I see the request in the log of my IIS. For the second I see nothing. I also tried to enable error tracing but did not find any request coming from acme-staging-v02.api.letsencrypt.org. So I have no idea who is throwing this 400-Error?
Maybe I will try the other win-clients later. For now I create again a self-signed cert, or just have to buy one 
Is there a wrong configured spam- or bot- detection? Or a firewall?
You can create a certificate using dns-01 validation and the --manual option. Then you have to create a dns txt entry (should always work), no running webserver (+ no ip address) is required.
But if your dns provider doesn't support an API, you have to do that manual - every 60 - 85 days. But you have time to fix the webserver-problem.
Hi, check that you don’t have a dynamic firewall rule or something else that is restricting certain requests. For instance connecting to your site over port 80 fails using Let’s Debug: https://letsdebug.net/remote.hobel.at/33814 so if you have dynamic IP restrictions or other firewall config (perhaps geographic) you may need to adjust or remove that.
I noticed also that sometime I have to click refresh because of an temporary 404.
But I have no idea why. I’m uring a Mikrotik-Router with an static NAT rule and the SBS in the private network. No other firewalls are involved. Even when I disabled the Firewall on the SBS temporary (which has no rule for this) the problem seems to be still there.
I also added ‘cacheControlMode=“DisableCache”’ to the web.config to ensure no result is cached.
If I have time, I try to setup a proxy with an nginix or apache and let the proxy handle all the SSL stuff… then I can also try much more (and better?) clients.