Getting AcmeServerDirectory
Newtonsoft.Json.JsonReaderException: Unexpected character encounteres while parsing value: <. Path ‘’, line 0, posiiton 0.
bei Newtonsoft.Json.JsonTextReader.ParseValue()
bei Newtonsoft.Json.JsonTextReader.Read()
bei Newtonsoft,Json.Linq.JObject.Load(JsonReader reader, JsonLoadSettings setings)
bei Newtonsoft.Json.Linq.JObject.Parse(String json, JsonLoadSettings settings)
bei Newtonsoft.Json.Linq.JObject.Parse(String json)
bei ACMESharp.AcmeClient.GetDirectory(Boolean saveReleative)
bei LetsEncrypt.ACME.Simple.Program.Main(String[] args)
My operating system is (include version): Windows Server 2008 R2 DataCenter
My web server is (include version): IIS 7
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):no
It doesn’t look as if letsencrypt-win-simple is fully maintained any more ( with the latest update at the end of July 2016) - There are various forks with updates ( https://github.com/Lone-Coder/letsencrypt-win-simple/network ) but there isn’t a single obvious favourite amongst those.
I’m sorry I can’t answer your questions fully, it’s not a client I’ve ever used (others here may have). Personally I’d be looking at using an alternative, better maintained, client.
Thanks for the references. Meanwhile I could bend my system to circumvent the proxy problem that caused my original cryptic error message.
After that, I noticed that letsencrypt-win-simple can only do http-01 challanges, not tls-sni-01 chellanges. As I don’t expose port 80 of the box in question that was somewhat of a show-stopper for me. Nevertheless, even after enabling port 80 in the firewall and adding a binding to port 80 with the desired fqdn, the attempts failed.
By quick glance, none of the forks seems to implement tls-sni either.
I suppose I’ll have a look at ACMESharp Powershell Commands and see what I can make from it (oh, guess what: https://github.com/ebekker/ACMESharp/issues/186 ). Then again, the best info about tsl-sni for that project that I can find is a “coming soon” dated January 2016 (and that’s probably a main reason for the same lack in le-win-simple).
Sooo, ultimately it looks like I’ll have to manage the certs from a linux box and then drill enough security holes to automatically transfer the necessary data between the linux and the windows box. Well, I still have three weeks until the current commercial cert of the production system expires - what could possibly go wrong
Maybe I should post here how I finally solved my problem.
My firewall allowed me to routing port 80 to a linux box while still routing 443 to the IIS server.
On the windows box, I have a Task-Scheduled Powershell script that - when necessary - uses “certreq.exe -new” to create a certificate request for a machine-certificate; for, the inf-file is created on the fly with a different friendlyName each time.
The CSR is the HTTP-POSTed to the linux box, which uses it to perform a “certbot certonly -webroot -csr” and returns the resulting cert (if successful) after a few seconds. (This required me to allow the id of the webserver to sudo a special wrapper for the certbot call, sigh)
Back on the windows box, the returned cert is used to complete the request (“certreq.exe -accept”).
Next, Powershell determines the thumbprint of the one machine-cert with correct friendlyName, removes the old binding and creates a new binding with the cert identified by said thumbprint.
Finally, “iisreset /noforce” should activate these changed settings, but as of now I still have to fiddle with the timeout settings for this before I can call my solution complete …
