Getting certbot webroot authenticator to work with IIS

[tech49]

After trying to figure out why my Lets Encrypt failed to generate in Windows, and discovering that it's the no extension mime type problem, I wondered whether certbot could fill in the missing gap.

All that is needed is the following web.config file to be placed in the same directory as the challenge

<?xml version="1.0" encoding="UTF-8"?>
 <configuration>
     <system.webServer>
         <staticContent>
             <mimeMap fileExtension="." mimeType="text/xml" />
         </staticContent>
     </system.webServer>
 </configuration>

Because there's no mime type for files without an extension on IIS, IIS sends back a 404 when verification happens. The web.config file above sets the mime type.

After I created the .well-known folder and the acme-challenge folder, and inserted the web.config there, it all worked fine.

Thanks

tech49

[griffin]

Welcome to the Let's Encrypt Community, Paul

You are absolutely correct in your observation and solution. There are many, many threads here recommending the same solution.

This is the downloadable version that I usually present:

web.config.txt (222 Bytes)

@certbot-devs

Is there any way this could be standardized into the Windows package?

I added a GitHub issue here:

In Windows deployment, add web.config file to acme-challenge folder so IIS can serve extensionless files when using the webroot authenticator for HTTP-01 challenges

[tech49]

Thanks griffin,
I did search the community for an answer, and clearly I was using the wrong search terms
Paul

[griffin]

No worries. It's fairly common (twice a month at least), but not easy to search out. Honestly, as you mentioned, this really needs to be baked into the certbot Windows deployment. It's a small price to pay in overhead to ensure IIS functionality right out of the box.

[Osiris]

@griffin

Is there any way this could be standardized into the Windows package?

As far as I know, there isn't really a "Windows package", that's just regular certbot stuffed in a Windows installer (so it includes Python et c.). Also, certbot doesn't include code to detect webservers on Windows, so while it might sound simple ("Just add a XML to the challenge"), I'm not sure if it actually is so simple. That said, one might think what the harm is to add that XML file temporarily to the challenge dir even when the webserver is Apache or nginx..?

[orangepizza]

well if there is explicit config to use apache or nginx then it's pointless, if webroot then can't assume about its folder structure

[Osiris]

@orangepizza

well if there is explicit config to use apache or nginx then it's pointless

The Apache and nginx plugins aren't available for Windows. So Windows users of certbot only have the option to use --standalone or --webroot.

[griffin]

@Osiris

That said, one might think what the harm is to add that XML file temporarily to the challenge dir even when the webserver is Apache or nginx..?

That was my exact thought. If one is using the webroot authenticator, just add the file. It's only like 222 bytes.

[tech49]

Personally, I think a lot of Windows users would be happy with an extra step in the Certbot - Windows Other (eff.org) page.

@Osiris pointed out that it's not the job of the certbot to detect or adjust the result based on the underlying server, and I can understand this.

Although I've asked that certbot handles this itself, this is really an implementation issue, and could be addressed in the Windows Installation Procedure. There's a hint of the problem in the "Important Note:", but this needs to be expanded.

For me, I tested that my server could serve files in the .well-known/acme-challenge directory. No problem there, and I naively used a test.html file. The problem wasn't serving files, the problem is serving files with no extension. The Important Note makes no mention of this.

The last part of the Important Note needs to read....

You will need to modify the IIS configuration to ensure that files without an extension inside /.well-known/acme-challenge are served by the webserver. This typically requires you to set a mime type for these files using a web.config file (provide link to example). To localise the configuration to the challenge directory, you can create the /.well-known/acme-challenge directory structure and create the web.config file there. Certbot won't remove the directory structure and web.config file if it already exists.

How's that. ?

[Osiris]

You could file a suggestion for this edit on Github. You can see the important note part here: https://github.com/certbot/website/blob/b07f109e838b0a57608fa351a91a2df0f2ba118e/_scripts/instruction-widget/templates/getting-started/windows.html#L81

You might even want to make a PR so the certbot team can implement any improvement quite easily. Or you could open an issue.

[griffin]

@Osiris

Just a heads up: I already opened an issue on GitHub and @adferrand has already self-assigned it.

[webprofusion]

It worth also noting that variations in the parent application config (particularly auth, but also things like ISAPI filter order) and different versions of IIS actually mean you can't use one config file to rule them all. By far the best solution is to skip IIS and use http.sys to register a listener for challenges (in front of IIS in the http pipeline). This is what Certify The Web and win-acme do by default.