Errror after WAF was installed

My domain is:


On a Windows 2019 Server using IIS 10 I tried to create certificates using WACS


It produced this output:] {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": " Invalid response from 404",
"status": 403


What's relevant to mention is that the client recently implemented a WAF and since that the validation isn't working. I read that Certbot could do a TLS ALPN challenge, however I'm not sure how to do this on a Windows IIS with WACS. There doesn't seem to be any docco on how to use TLS. I was really hoping this was an easy answer to you experts?

Thanks in Advance

1 Like

You are currently using http validation (possibly the self-hosting option which bypasses IIS) so for that you must be able to respond to the request on TCP port 80. You cannot block port 80 and complete http validation at the same time. Note that if you don't normally have any active port 80 listeners (e.g. IIS bindings) then there is no significant security risk to having the port open, unless you count the win-acme listener which only runs during validation.

win-acme does have a tls-alpn option: win-acme

Another option is DNS validation but that depends on the capabilities of your domains DNS provider.


Thanks for your clear response mate.
I believe the WAF is blocking port80. so they would need to open that (as you suggested perhaps I can disable the port80 bindings to help alleviate their security concerns).

I tried the win-acme tls-alpn option: by choosing option M in ACME then following the prompts to do a TLS-ALPN-01 challenge. However I got the following error

TLS-ALPN-01 challenges will use port 443 [not port 80].


Yeah sorry I don't know - self hosting http challenges on port 80 works ok because http.sys allows sharing the http pipeline, but I've never tried to share port 443 in the same way, I've a feeling you can't, so presumably you'd have to stop IIS.


I tried stopping IIS on that site. But got the same error.

I think every single WAF out there is fundamentally incompatible with TLS-ALPN, because they only understand HTTPS and will just ignore the acme-tls/1 ALPN.

DNS has already been suggested as an alternative, but I would also suggest trying a webroot approach as well, if your website in IIS has a document root. win-acme seems to call this the filesystem plugin.


Good idea, I was assuming http was outright blocked but if it's redirecting to https successfully then you could indeed serve the challenge from the web server itself instead of letting the app host the challenge response service. The key trick with IIS is to configure your challenge response directory via a web.config so that it serves the extensionless text file OK. The way we do it in Certify The Web is to automatically fallback to the IIS (webroot) method if the challenge server method doesn't succeed but perhaps in win-acme you have to configure that.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.