Slight correction. If the IPv6 address fails to connect it will move on to IPv4. If the IPv6 attempt returns an invalid response, it’s done there. Jsha confirmed in a post several hours ago that there are no plans for this behavior to be changed. If your server returns erroneous responses to IPv6 requests when you are advertising an IPv6 address, either the server needs to be fixed or the AAAA record needs to be removed.
Finally got the certificate, but none of the programs (certify, win-simple) worked. Found a web based site (sslforfree.com) that manually generated the certificates and key files. Then I had to use OpenSSL to create the pfx file.
Also, I had to temporarily remove ASP from the website as I could not get the initial authorization to work with ASP enabled. (Letsencrypt needs to remove the leading dot on folder names). Handlers and/or mime settings do not work.
It was a lot of work and I had to do everything manually but the end result is a working cert. sslforfree.com works because it must have a different method of dealing with the verification files but even this would not work with ASP.NET enabled on the website. Once sslforfree generated the certs, I could proceed with a manual installation and reactivate ASP. Not for the inexperienced to attempt.
I host my website myself and have full control over my onsite Windows 2012 R2 servers
The dot before well-known is per RFC 5785 and is an IETF standard. That’s not up to Let’s Encrypt to change.
Dude. I run IIS 8.5 and knew nothing about certificates prior to this June. Everything works fine for me, I just had to ask a lot of questions here and do a ton of research and reading. I used the ZeroSSL CLI tool LE-64.exe and the big things for me were:
-
run commands while remoted into the server with an account that is a member of the Administrator group.
-
get IIS to allow files without an extension. I added this mimemap to my web.config (obviously do not duplicate the sections if they exist):
<system.webServer>
<staticContent>
<mimeMap fileExtension="." mimeType="text/plain" />
</staticContent>
</system.webServer> -
Get a .PFX file to install into the certificate store. I installed OpenSSL (latest version!) since I didn’t trust a public webserver with my private key to do the conversion, and ran this command:
openssl pkcs12 -export -out myWebCert.pfx -inkey mydomain.key -in mydomain.crt -
I noticed there are two ways to (manually) install a certificate: one is to use the IIS console, the other is to add the Certificate plug-in to the MMC console and use that. The latter way allows you to edit more items related to your certificate.
-
You’re done! I am going to look into automating this process using the
LE-win-simpleprogram so I don’t have to keep manually updating my cert, which might generate a lot more questions lol.
Ok, but does your website use ASP?
Using the mime addition does not work for me.
Only disabling ASP worked without any Mime or Handler changes.
And I did this right after a fresh install of Windows 2012 R2 and an install of Smartermail which uses ASP extensions.
I am sure if all you have is a plain static website, you would have no issues.
Maybe that Smarteremail made some changes that broke the configuration? I’m using lets-encrypt-win-simple (via Azure Web App Extension) for an ASP.NET application without issues validating using http-01.
No, I’m a developer and do a lot of ASPX coding, our webpages are very dense with database connectivity and Javascript libraries. I’d look into what changes that smarter app made to your config files, it probably mucked things up. Also, if it was a fresh install, I hope you installed all the patches first…
Yes all the updates were done first. I would think if the config files were the problem, it would not have worked with ASP disabled.
I do see some additions to the web.config from Smartermail, but nothing seems like it should affect the letsencrypt validation. I will try some more tests on my test server.
You need to supply more info to get help troubleshooting your issue. I cannot see how “disabling ASP” can affect certificates “working” or not. LE doesn’t care what language your website is built in. It requires access to certain website directories (http-01) (see my note above) or DNS (dns-01) (which I don’t know about). IIS uses special config files (web.config & application.config & machine.config) which must be setup properly based on the unique requirements necessary to run an SSL website, but nothing too difficult. You need to ensure that your firewall allows traffic over port 443 for SSL (and port 80 for LE http-01 validation.) Turn off all rewrite rules until you get it working. Determine if you are using SNI or not since that affects the certificate data (SAN). Read up on all of this!
First off, I have no issues or problems installing or using certificates. I already have the letsencrypt certificates running fine. But I will have issues when I try to renew. The issue is with the verification process, not the certificate process.
If I do not disable ASP, then leading dots on folder names is not accessible from the internet. Using Handlers and mime entries does not work to fix this for me. There may be some other code running that prevents this, who knows. But bottom line is my systems cannot accept the leading dot on a folder name which causes the verification to fail.
After I got past the authentication, I was able to create the certs and are working just fine now.
The entire issue is in the verification stage to get the certs. Once I was able to get past this all went normally. So there is no problem with ASP or any config files, it is a problem with trying to get the verification stage to pass. If Letsencrypt did not use a leading dot on their verification folder name this would not be an issue. If they do this because of some protocol standard, then the standard is not industry wide compatible and needs attention. Probably an old Linux throwback standard.
It's pretty clear that the leading dot is inspired by the fact that files beginning with a dot are hidden by default on Unix. This behavior predated the existence of Linux by around 20 years; it was accidentally introduced in Unix version 2, as Rob Pike explained at
Pike thinks that it was a mistake and it's certainly caused plenty of confusion over the years, although it's also convenient to be able to hide configuration files. The behavior appeared because the directory listing program ls was designed to hide the special entries . and .. (current directory / parent directory, which you also have on Windows with the same names), but it did so using a trivial implementation that simply omitted any entry beginning with a dot. Pike thinks that, instead,
They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files.
Anyway, I'm sorry that it's inconvenient to configure your IIS to serve files whose names begin with a leading dot when ASP is enabled. It seems like other people must have found workarounds for this or further configuration options that affect it, since we do have a considerable number of users on IIS and all of them have to pass the same challenges as everyone else. This makes me think that there's probably a straightforward existing option that can be changed to allow serving files that begin with a dot.
Do you have any contacts at Microsoft or familiarity with IIS forums? If not, maybe we could post a new topic here that's more specific and maybe other IIS users can contribute tips.
As other people may have pointed out, this is rooted in RFC 5785
and in turn has been (sort of) required by the CA/Browser Forum Baseline Requirements
See section 3.2.2.4.6. However, this is only "sort of" required because they also allow using a different path registered with IANA for this purpose, and indeed Let's Encrypt registered /.well-known/acme-challenge in place of /.well-known/pki-validation. But I don't know that IANA will currently allow registering paths outside of /.well-known, because it's RFC 5785 that grants them the authority to reserve paths this way.
If it must be done this way, then we need a definitive guide on how to make it work in all instances of IIS including ASP.
Windows obviously has an issue with the leading dots especially using ASP. I also have a problem with making changes to IIS which involve possible security risks just so letsencrypt can pass validation once every 90 days. There has to be a better solution. And yes people have it working with lots of fudging that we have to do every time we renew. That does not make it acceptable.
Have you considered the dns-01 challenge type?
The DNS type wants Azure info which I am not using. Also not using virtual folders or machine.
Anyway, unless that type reads the folder differently, would make no difference.
Would you be OK with a new forum thread whose title is specifically about ASP and dotfiles? I feel like we have other people on the forum who must have looked into this, but they might be more likely to contribute their expertise to a thread with a more specific title.
Good idea. I will do it.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.