how about an option to do the authentication using a user selected folder instead of .well-known
Leading dots are a real issue for IIS and other users in the folders.
how about an option to do the authentication using a user selected folder instead of .well-known
Honestly, this just sounds like a way to introduce excessive vulnerabilities to the process for any host that allows users to upload files that could be served by the webserver.
.well-known is a standardized (in RFC 5785) path for many similar use-cases, so it makes sense for Let’s Encrypt to use it for the purpose of domain validation.
Leaving that argument aside, allowing arbitrary paths would be a bad idea for a number of reasons.
The CA/B Forum, which releases the Baseline Requirements, a set of industry rules which all publicly-trusted CAs have to follow, has decided that only paths under
.well-known are permitted for the purpose of domain validation over HTTP. Using other paths would be a violation of these rules and could lead to browser distrust of Let’s Encrypt.
These rules weren’t made for no reason: In the past, the Baseline Requirements were far less explicit on this, causing each CA to implemented a different variant of HTTP validation, often using different paths. This caused a lot of issues for websites which allowed users to post arbitrary content to most paths (think: GitHub Pages) because they’d have to check the path used by every single CA and block those manually. Allowing user-defined paths would be even worse (I don’t think that was done by any CA in the past) because you’d practically have no way to operate a site with user-generated content without also giving your user the ability to get a TLS certificate for your domain. With
.well-known, there’s exactly one path to protect, so while it’s not perfect, it’s at least doable.
if this path is protected, how does the ACME server authenticate over the internet? If the ACME server can get to it, so can everyone else. So this argument doesn’t make sense to me. Beside the data stored there is not anything special, just some random characters. This path is not a link to the certificate itself.
And lets face it RFC 5785 comes from Linux developers and has no usage or purpose in a Windows environment.
Regardless, leading dots don’t work nicely in a Windows environment so maybe these standards need updating.
By "protected", I'm referring to the ability of users to write arbitrary files to the path. If you're running something like GitHub Pages, you typically allow users to upload files to arbitrary paths under their domain, and HTTP clients will be able to request those. When it comes to domain validation, allowing this is equivalent to giving them the ability to get a valid TLS certificate (from Let's Encrypt or any other CA with HTTP validation support). By requiring that all this has to happen under a path in
.well-known, GitHub can block you from writing to that path, and there goes your ability to get a certificate for their domain.
I'm not sure what gave you that impression, but this is an IETF document. The IETF is where specifications for all major internet protocol come from (HTTP, TLS, DNS, ...). They're all pretty much OS-agnostic.
You'd have to bring that up in the relevant IETF working group. However, I don't believe the fact that some extra work is required on some platforms is a good enough argument for a change here.
Similar to the situation on Windows, there are hundreds of configuration examples for apache and nginx out there that contain lines preventing paths starting with a dot from being served. This was often done to prevent leaking source code if there's a
.git directory (or similar) present under the web root. These configurations simply need to be updated to exclude
.well-known from this rule, and that's quite similar to what you need to do on Windows. If that doesn't work for you, alternative challenge types such as
dns-01 are still an option.
It's pretty easy to create leading-dot files and directories in Windows, especially in PowerShell, or inside a program. If you're manipulating files in Windows Explorer, it won't work so well, but any good Windows admin nowadays should have some basic PowerShell knowledge since many of Microsoft's new tools lean heavily on it.
First off, if you do not write protect your web folders then shame on you. You should always do that. And leading dot directory names are very rarely found in Windows environments. Creating them is one thing. That is easy to do and that is not the issue here. Letsencrypt actually automatically creates them for you.
The issue is accessing them in IIS ASP sites. Now I do realize that MS should have implemented this better, but forget about any changes taking place there. Set aside the rules and standards. I just want a solution that works.
I'm guessing you're not familiar with how sites like GitHub Pages work - they're essentially a way for you to publish a website under a subdomain dedicated to your user or repository. Giving you write access to your web site is the use-case. This should not automatically mean that your users can get TLS certificates for that subdomain, and with
.well-known, you can prevent that from happening by blocking just one path.
Plenty of options exist, both in terms of alternative challenge types and ways to make it work on IIS. One option was pointed out to you in the other thread.
Then perhaps follow the solutions presented to you elsewhere on the forum?
I'm going to be honest, it sounds like you're saying "it doesn't work for me how I think it should, therefore it's wrong." This isn't a valid way of looking at things, nor is it a particularly valid justification to alter existing standards.
Criticizing is not a solution.
Not sure what you meant by alternate challenge types. If they still use the leading dot, they will not work. I cannot access a directory via the internet with a leading dot as the name.How many times do I have to repeat this fact. How do I get past this. Suggested mime settings and Handler changes, which are security risks, do not work.
I don’t know how your system is configured, but by default IIS will serve dot-paths, which are easily created by commandline or by certbot, and certbot works just as well for me on IIS7 as on Linux. (Though it took a few tweaks to get it running.) So it’s obviously something you configured that stopped it from working. Maybe you installed URLScan without adding AllowDotInPath=1 in URLScan.ini?
There are three challenge types accepted by the Let's Encrypt CA:
http-01 (testing the ability to create a specified file that can be accessed via HTTP within
/.well-known/acme-challenge in a request to the specified domain name on port 80),
tls-sni-01 (testing the ability to create a specified certificate that will be returned in a TLS negotiation in response to a ClientHello requesting a particular virtual host ending in
.acme.invalid in a connection to the specified domain name on port 443), and
dns-01 (testing the ability to create a specified DNS TXT record referring to a subdomain of the specified domain name that will be returned in response to a DNS query). Only
http-01 makes an HTTP request to a web server; the other two challenge types don't.
http-01 is the most widely used because it is conceptually the simplest to implement, but the other two challenge types are accepted for all the same purposes, and the ACME client requesting the certificate can choose which challenge it wants to perform for each domain name.
There are a lot of IIS users who are successfully getting certificates from us by some means. It is a very legitimate question to figure out the best way to do this using IIS and to find out what other people's best practices are (and also whether we should request a particular configuration option from Microsoft). In another thread someone linked to something that looked promising to me, but you can of course respond in that thread and identify any concerns that you might have with it. Although the Internet standards that we're talking about certainly historically influenced by Unix users, we have lots of satisfied Windows users who have ultimately found some way to make their environment interact satisfactorily with Let's Encrypt's services, and complaining about bias in RFC 5785 is probably ultimately off-topic for this forum. (You can bring it up in the CA/Browser Forum or in the IETF ACME working group if you'd like. Nobody of this forum has the power to change this practice or convention unilaterally, but we all want to find solutions that work well for each user regardless of their hosting environment.)
Edit: as an analogy, the fact that HTTP uses
/ as a directory separator instead of
\ is also influenced by the fact that Tim Berners-Lee invented the web under Unix rather than Windows, since the forward-slash directory separator is totally characteristic of Unix. Nonetheless, IIS manages to map
foo/bar in URLs to
foo\bar in local Windows paths, because that's what the Internet standards world ended up agreeing on.
Thanks very helpful. I did already generate the certs using a site like gethttpsforfree.com. Actually I used sslforfree.com which worked great but required a lot of extra work to make the pfx file. I want to automate the process to make renewals easier.
So I realize I cannot use HTTP-01 which seems to be the only method used by win-simple and Certify, the only two Windows based programs I have found. I will have to research what ACME clients are available for Windows where I can use dns-01. And suggestions would be helpful.
ACMESharp seems to support
dns-01 as well, Using this requires some PowerShell familiarity and the docs for
dns-01 seem a bit out of date.
That said, perhaps this suggestion from your other thread might work as well:
lego look promising since my dns provider is listed. I will try it.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.