It has been suggested to start a new more specific thread on this issue, so here it is.
Please post here if you have any methods or solutions to overcome the leading dot issue when letsencrypt is trying to authenticate when using IIS with ASP enabled.
mime and handler changes are not acceptable solutions because they do not work for me and some others beside imposing a possible security risk.
If I understood what was being advised there properly, that seems to have the advantage of being highly specific, so if you don’t want to change the overall behavior of IIS in terms of what files it will and won’t serve, you can still change it for this particular path.
Are you sure that the problem is the leading dot in the directory name? If so, just drop to a command prompt and CD \inetpub\wwwroot into the root directory of your website, then MD ".well-known" and voila! You must use the double quotes but that will create the directory for you. Then you can get into it with CD ".well-known" (again, must use the quotes) and MD acme-challenge and you’re all set up. I did it myself manually, but the various Let’s Encrypt tools will create the appropriate files and copy/delete them, etc during the cert process.
If the problem is actually that IIS won’t serve the resulting http-01 challenge file because it does not have an extension, then you must make a new mimemap entry to your web.config file like this:
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension="." mimeType="text/plain" />
</staticContent>
</system.webServer>
</configuration>
Recycle the application pool attached to your website and it should be good to go! You did not mention if this is using MVC, which has a whole other set of issues…and also IIS 6 is outdated so hopefully you’re using IIS 7 or higher.
The latter is the case for this individual, who has also repeatedly refused to alter his MIME/handler setup for "security reasons" in both this and other threads:
Huh. Well, I can’t think of any security risk in allowing files without extensions to be served, since security through obscurity is not security. However, this is a Microsoft thing in IIS and it simply won’t work without that capability. If he doesn’t want to enable this simple web.config required change only for the challenge process, then copy back his original file then I suppose he could install nginx or some other Linux variety to perform the challenge, then import the certificate into IIS, but that’s too much effort for me. :- )
Is there, maybe, a way to limit the effect of this mimeMap to files with the literal name .well-known?
Some people on various systems like the idea of forbidding files starting with . from being served by default because of a lot of credentials and keys (.htpasswd, .ssh, .gnupg), temporary files (.swp), and editor or version control configuration files (.git, .travis.yml, .gitignore, etc.) will have that name. I do think this default has prevented a huge number of accidents where people kept these in their web content trees and where they would accidentally be made available to the public. So, I don’t think we need to take any kind of hard line against this precaution. Still, intentionally serving the specific path /.well-known doesn’t seem like a security risk because it’s specified by an Internet standard and there’s no particular reason to expect this path to inadvertently contain any confidential information.
I think there’s a big misunderstanding here. There is no “invisibility” of directories that begin with a period in their name in Windows, that’s a *nix thing. There is nothing special needed in IIS to allow a directory that starts with a dot to contain content pages which get served via http/https. Saying there is a problem with IIS serving a file that is located within a directory path that starts with a period is an error, because this is not prevented even in a default setup of IIS.
The issue, outlined above, is that IIS by default will not serve any files with extensions that it does not know about. Such as filenames without an extension at all. As an example, it does not know about .woff files (special font format) or .svg image files, so you have to add a mimemap for those also:
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
Without these mappings IIS will give a 404 error for those file types. I don’t know how much he knows about IIS configuration, but perhaps he is expecting to use a browser and go to that directory to see the files listed? By default IIS will not display a directory listing for security purposes; that has to be specifically enabled in the settings. And, again, MVC is a whole 'nuther thing.
The nuclear option would be RAMMFAR (Google it) but I highly discourage that…there’s always another way. Also, if he is running URLscan then that could be the culprit too.
I think the use of ASP somehow changed things for the original poster with regards to dot-directories.
Hi @dcol,
I use LetsEncrypt-win-simple (aka LetsEncryptSimple) on MS Windows Server 2016 with IIS 10.0
It now works fine for me after taking 2 steps:
1: I added a Web.Config (text) file in the subdirectory .well-known of the webroot of the IIS-website
Web.config.txt (176 Bytes) please remove the .txt extension after downloading.
2: modification of the LetsEncyptSimple file web_config.xml
web_config.xml.txt (784 Bytes) please remove the .txt extension after downloading.
To test this setup I created an extensionless text file named Test with “Test OK!” in it (make file Test.txt first and remove the extension .txt)
If you can see Test OK! when you visit the url: "http://www.yourdomain.com/.well-known/acme-challenge/test
then you’re configuration should also work with LetsEncryptSimple!
(unless you have other issues, like I did: an incorrect CAA DNS-record…
)
I hope this helps!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
