Noob here.
Due to network security circumstances my HTTP challenge server must be a different endpoint than the IIS server receiving the certificate via Certify. I have configured a Linux machine running Apache in a DMZ separate from the IIS server and need to be able to create a symlink from wherever Certify wants to put the .well-known/acme-challenge files on the IIS server to the server in the DMZ. Does anyone know where the .well-known/acme-challenge folder is on the IIS/Windows machine?
The site’s detected root is where Certify would place the files if it were using IIS instead of its internal challenge server. If it were using the internal server, it would make Windows direct .well-known requests to it using port sharing… I’m not sure if there are physical files with the internal server.
Certify doesn’t require that you have a working IIS instance. You can manually set the site’s root folder to where ever you want and it will still bind the certificate to the site you selected. This is the route I suggest you take instead of trying to intercept things. Just create a folder on the Windows machine that you know will work for the remote Apache server… then point Certify to that.
I don’t have a copy of v4.x in front of me… but in v5.x you select the IIS site in the Certificate options and set the Site Root Directory in the Authorization options. You may have to check the Advanced checkbox to see everything.
Thanks @jljtgr!
Thinking about this though, the only way I can think of for you to get this is to work using http validation is to proxy /.well-known/acme-challenge request through to your IIS server, then let that box handle the http validation response required. This means your apache server probably can’t also use let’s encrypt http validation unless you redirect validation 404s to the IIS server
The correct way to do this is to switch to DNS validation and use either one of the DNS APIs or acme-dns. You could also put the Apache server in charge of certificates and script a regular export/conversion of it’s certificates to a PFX and install it on IIS, but that wouldn’t involve Certify (currently).
Thank’s for the responses.
It worked, sort of.
I setup my Linux/Apache server in a DMZ zone separate from the LAN the IIS server is on.
Configured my firewall to forward port 80 to the Linux box so the outside world can see it. Configured an alias in Apache called .well-known/acme-challenge. Made sure it was accessible from the outside.
Configured Samba with a public share called “acme” accessible only from my IIS box IP address.
Created a symbolic link from the IIS box to the Linux box using “mklink /D C:\inetpub\wwwroot.well-known\acme-challenge \\acme”
Disabled the built-in HTTP challenge server in Certify so that it would place the challenge file in C:\inetpub\wwwroot.well-known\acme-challenge which we’ve tricked to point to the Linux box.
The certificate was issued and installed on the IIS server.
It reported that it bound to the website (Default Website) but the binding never actually happened.
I did ignore a warning on launch of Certify that I do not have Powershell 5 installed. Is it possible that is the reason the certificate did not bind to the site? The IIS box is Server 2012 R2.
Ok, got the binding working. Changed the deployment mode from Auto to All-sites and checked all three boxes. Then went to the certificate screen and under advanced options selected “re-apply certificate to bindings”.
The only thing I can think of that might have caused that is none of your IIS sites had a binding that specified your domain name. So when “Auto” searched your bindings, none matched to be applied.
The Preview tab is your friend and will show you a dry-run of the bindings updates.
The current configuration you have sounds like IIS didn’t have any matching hostname bindings (as @jljtgr says) so naturally the app has no idea which website bindings to update, that’s why forcing it with Binding hostname not specified worked. If you imaging web servers running 10,000 websites each with different domains you can probably see why hostname bindings are useful!
Sounds like you’ve got it working though, great! I would absolutely have used DNS validation (probably with acme-dns) in your case, unless you have no control over DNS.
As a side note, as of a few days ago the backend portion of Certify The Web now works on linux, and you will be able to daisy-chain instances (one install pull certs from another, cross-platform), this means you could do http validation with apache on linux and pull + deploy that cert on the windows machine.