LE64 creates acct, updates email - but that's it


#1

My domain is:


fundamentaobjects.com

I ran this command:


le64 --key account.key --csr-key mydomain.key --csr “fundamentalobjects.csr” --crt
mydomain.crt --domains “www.fundamentalobjects.com,fundamentalobjects.com” --path /.well-known/acme-challenge/ --generate-missing
–update-contacts "my-email@fundamentalobjects.com" --debug

It produced this output:


I am running the 64 bit Windows le64.
I pre-created the account.key, domain.key and CSR file.

The above line registers the account.
It also updates the email address.
But that’s it.

Nothing shows in the challenge folder and no other files are created/modified.

No output on anything but the account key processing and email being updated.

–debug does not seem to produce anything different.

I have tried it with a full windows path to the challenge folder as well. And with the path in & out of quotes.

My web server is (include version):


IIS 7

The operating system my web server runs on is (include version):


Windows 2008 R2

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.


#2

Hi,

Where is your script name


#3

Hello Steven

That line is being executed as shown in an Admin command prompt.

le64 is the compiled Crypt::LE app for Windows.


#4

Update:

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.


#5

Hi @LEForTheWin

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.


#6

Thank you Juergen.

I just left off the \ when posting my comment.

It is correct in the script,
and I copied it to file explorer to check,
just to be double sure.

I think le64 is trying to hit the correct folder, because I do not get the “can not write” error if I leave off the trailing “\”.

In the case of no trailing \, there is no error at all.


#7

Looked if there is a documentation. Found that:

le.pl --key account.key --csr mydomain.csr --csr-key mydomain.key --crt mydomain.crt --domains "www.mydomain.com,domain.com" --path /var/www/html/.well-known/acme-challenge/ --generate-missing --unlink --live

Your path must be the complete webroot. So use something like

c:\wwwroot\.well-known\acme-challenge\

And use the windows - backslash “”, not the website “/”


#8

Thank you.

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.


#9

Hi. Just trying to understand what is happening here, so feel free to correct me if my understanding is wrong :slight_smile:

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?

echo “Test” > c:\wwwroot\.well-known\acme-challenge\123.txt


#10

Firstly – THANK YOU ALL for your help!

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

le64 --key account.key  --csr fundamentalobjects.csr --csr-key mydomain.key --crt mydomain.crt --domains www.fundamentalobjects.com,fundamentalobjects.com --path c:\wwwroot\.well-known\acme-challenge\ --generate-missing --update-contacts myemail@fundamentalobjects.com

I get only this output

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.


#11

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.


#12

PROGRESS!

OK, pulling the update email did move me forward.

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.

I originally had www.fundamentalobjects.com, fundamentalobjects.com, www.fundamentalenergy.com, fundamentalenergy.com and the .csr matches that.

but before I switch it

a. How should the --path be set up if I wanted to do both?

  • Just a separate --path for each of the 4?
  • One --path with the folders for each of the 4 comma-separated? (there are only two domains there really)

Hopefully our write-up will save this forum questions and your time, down the road.

#ThankYou


#13

404 - File or directory not found.

I have punched past the path
(even though it is generating 5 challenge files for 4 domains).

le64 now fails on a 404 for the challenge file.

  • the challenge file gives a 404 from an outside browser,
    but a sample.htm opens fine.

So it is Windows HTTP having an issue serving up a guid-ish file,
without a known to IIS extension.

I am trying to chase down that answer.


#IAmThisCloseToACert


#14

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:


#15

Yes. You have to create a mime-type *. / text/plain.

Test, if you can open a file

/.well-known/acme-challenge/123456789


#16

More progress.

(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.)

  • Now 1 cert is shown, www.fundamentalobjects.com and
    clicking that shows that it holds all 4 domains.

    (these share the same IP)

  • 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.

  • that is, opening https://www.fundamentalenergy.com/ in a browser takes you to fundamentalobjects.com instead.

  • Best of all, the lock icon for fundamentalenergy shows it as being from Let’s Encrypt, but *not fully secure".

I do/did have cloudflare in the mix.
I have it’s settings correct for SSL I believe.

All above is just an update.

I’m still plugging away.


#18

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.

http://www.fundamentalobjects.com/images/hl-1.jpg


#19

Thank you, that helps.

Did you notice that when you ctrl+shift+I on fundamentalenergy that you are actually viewing the source of fundamentalobjects.com?

(you are)


#20

If I load https://www.fundamentalenergy.com/ - then the url doesn’t change, there is no redirect.

Fundamental Objects, Inc. provides our clients with the business solutions that they need to achieve success.

is part of the content.

https://fundamentalobjects.com doesn’t work:

This site can’t provide a secure connection

fundamentalobjects.com uses an unsupported protocol.

Unsupported protocol

The client and server don’t support a common SSL protocol version or cipher suite.

This is from Opera, same with FireFox.

Perhaps use https://www.ssllabs.com/ssltest/ to check your settings.


#21

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).