I have managed to push past that and am now at this error:
2018/08/25 18:02:35 [ ZeroSSL Crypt::LE client v0.31 started. ]
2018/08/25 18:02:35 Path to save challenge files into should be a writable directory for: c:\wwwroot.well-known\acme-challenge
The folder is writable.
And again, this is being run as admin in an admin command prompt.
shure that your --path - option is correct? If your webroot-folder is c:\wwwwroot, then the subdirectory should be c:\wwwroot\.well-known\acme-challenge.
So there is a missing "" in your error text.
But I don't know if this is a result of your input or if it ist a bug.
Up in my original post, you'll see that I tried the full windows path as well.
(I've been working from that zeroSSL page -- it's pretty good.)
Still stuck on the acme-challenge folder getting a
"2018/08/25 19:09:08 Path to save challenge files into should be a writable directory for: " my windows path -- where acme-challenge is indeed writable.
Hi. Just trying to understand what is happening here, so feel free to correct me if my understanding is wrong
Windows binary of le64 is run under Windows 2008 R2 with enough rights, but it stops with an error saying that the path to save the verification files is not writable. Now you are saying that error was happening if the path was given as: "c:\wwwroot\.well-known\acme-challenge\" (with the trailing slash), but there is no error if no trailing slash is used? Could you provide a bit more details regarding the exact commands being run and the resulting output (privately if you like, via local private messaging or the contact form on ZeroSSL)? That would help in reproducing this.
Additionally, just to make sure that folder is indeed writable, could you try running something like below from the same command line and see if the file 123.txt has been created with "Test" in it?
a. this indeed creates the file.
echo “Test” > c:\wwwroot.well-known\acme-challenge\123.txt
b. I now believe the “not writable folder” also comes if you have an error in the folder path string. Using c:\wwwroot888.well-known\acme-challenge\123.txt gives the same error.
I now think I had the folder right to start – and getting NO error was the correct thing.
c. Current state
When I run the Windows 64 bit binary, with the below string
2018/08/26 10:01:23 [ ZeroSSL Crypt::LE client v0.31 started. ]
2018/08/26 10:01:23 Loading an account key from account.key
2018/08/26 10:01:25 Registering the account key
2018/08/26 10:01:26 The key is already registered. ID: my number here
2018/08/26 10:01:26 Current contact details: myemail@fundamentalobjects.com
2018/08/26 10:01:26 Contact details have been updated.
No files created in acme-challenge or other files modified.
OK, now that makes sense why the process ends there. As per the documentation:
If you would like to receive expiration notifications for your domain, you can specify --email parameter and an appropriate email address during the initial registration of the account. Later, shall you want to change your email or specify more than one, you can use --update-contacts parameter to update your contact information.
What I probably should have made a bit clearer (and I will outline that in the documentation later) is that since there is no specific command for issuance (which is the default mode of operation), using --update-contacts or --revoke options is recognized as requests to do just that - "update contacts" or "revoke the certificate" and exit. This means you just need to drop --update-contacts option from your command line for the process to continue further.
Also on Windows I would recommend taking the values for the parameters (such as path) into double-quotes. Please give it a go without --update-contacts (and with "quoted path" if you are still getting an error regarding the path not being writable) and see if that works for you.
If you bear with me, we are writing this all up for Windows Server accounts for an ISP (along with a guide on moving from Windows to GNU/Linux) which we will give back to LetsEncrypt once finished.
So -- one more question Please?
(I can open a new topic, if desired).
I get this error now, which makes sense.
018/08/26 17:31:37 Could not load a CSR: The list of provided domains does not match the one on the CSR.
Regarding the questions of the domains on the command line vs those on CSR - this is basically a safeguard, so it is a good idea to always provide both. If you are getting a mismatch error and you are sure that the list on --domains is correct, then deleting the CSR will re-generate it with the names as given on --domains.
Regarding the case when there are different “webroots” for the domains - you can specify them with a single --path parameter as a comma-separated list (in the same order and amount as the domains listed with --domains).
Finally regarding the IIS and files with no extensions. To allow IIS to properly serve files without an extension, you can (temporarily) add an appropriate MIME-type. For example as described here:
(Although it feels a lot like the Verdun battlefield)
got the cert created. #Woohoo
openssl’d it to a .pfx, adding the password.
Did not try to command line auto-apply it, because I did
not want to guess at the myriad of cert areas to apply it to
(which you would have to name in the openssl call)
so I double-clicked the .pfx and let Windows do it.
Windows asked for a password and said it was done successfully.
No cert showed in IIS.
So I imported it directly in IIS.
ps
(I refreshed, restarted, Application pools, websites and IIS itself liberally, throughout this process.)
in IIS, I bind 443 to the IP for each,
but you can not specify the domain string for 443 in IIS 7.
It appears to pick up and use www.fundamentalobjects.com from the cert for them all.
This is only a mixed content warning. The certificate is correct. Use FireFox or Chrome, Ctrl + Shift + I, open the console. There you see a lot of http - links: Change them to https.
Just a quick note regarding this - you don't really need OpenSSL to produce a pfx, the LE client on Windows can do it for you while getting a certificate, as described here:
le64.exe ... --export-pfx "mypassword" --tag-pfx "My own Friendly Name"
This will additionally save a pfx along with the usual PEM file (--tag-pfx is optional, but useful to add some meaningful description to PFX, which is later shown in the UI console).
