I run this command in a batch file and get these results. It also leaves a file named “-8zgZWkKs5cWYUGEFtlF6zG3YSyEq3uGcsGk6pCcOzw” in the acme-challenge directory. What gives?
C:\ZE>le64.exe --key account.key --csr mydomain.csr --csr-key mydomain.key --crt mydomain.crt --domains "domain.com,www.domain.com,cms.domain.com,mvc.domain.com" --path "\inetpub\wwwroot\.well-known\acme-challenge,\inetpub\wwwroot\.well-known\acme-challenge,\inetpub\cms.domain.com\cms\.well-known\acme-challenge,\inetpub\domain.com\.well-known\acme-challenge" --unlink --renew 11 --issue-code 100 --live
2019/08/09 10:47:52 [ ZeroSSL Crypt::LE client v0.33 started. ]
2019/08/09 10:47:52 Loading an account key from account.key
2019/08/09 10:47:52 Loading a CSR from mydomain.csr
2019/08/09 10:47:52 Checking certificate for expiration (local file).
2019/08/09 10:47:52 Expiration threshold set at 11 days, the certificate expires in 7 days - will be renewing.
2019/08/09 10:47:53 Registering the account key
2019/08/09 10:47:53 The key is already registered. ID: redacted
2019/08/09 10:47:53 Current contact details: webmaster@domain.com
2019/08/09 10:47:54 Successfully saved a challenge file '\inetpub\wwwroot\.well-known\acme-challenge/fr_wxAu2UEIOqAhsPS7iwNrBUu1msJkbU0uW_QLIII0' for domain 'domain.com'
2019/08/09 10:47:54 Successfully saved a challenge file '\inetpub\wwwroot\.well-known\acme-challenge/JQOpR701F-773DgjUmwVYZuiHWAEOKdGCeXItltE70A' for domain 'www.domain.com'
2019/08/09 10:47:54 File already exists - this should not be the case, please move it or remove it.
2019/08/09 10:47:54 File already exists - this should not be the case, please move it or remove it.
2019/08/09 10:47:54 Challenges failed for domains: cms.domain.com, mvc.domain.com
What is happening with the “file already exists”?
Thanks for any help!
Hi @mushu, this is not something anyone had reported before and should not indeed be the case. A few questions:
Is it the first time you are running this under Windows Server 2019?
Does the problem go away if you switch to api v 2 (–api 2)?
How many verification files you are finding not deleted and are those new (created after running the client) or pre-existing, for example from some earlier run without --unlink?
If it is more than one file, is there anything in common regarding their naming (say all start with ‘-’)?
Does the problem go away if you delete all stale verification files under your challenge directories and re-run the client?
Could you also PM me the debug output for this, using --debug --debug (like that, twice) and removing any info you believe might be sensitive? What is happening there seems to be the following - you have 4 domains for which the challenge is requested, there is then an attempt to create 4 verification files, which are named according to the token, and for some reason for the last two domains system reports that such file already exists. Considering that token is expected to change if you have failed an attempt previously, that seems unlikely. Some additional details might help to see what is going on there.
P.S. Also please double-check whether the permissions on the last 2 folders you have specified in the --path are anyhow different from \inetpub\wwwroot\.well-known\acme-challenge.
this is not the first time running under Server 2019, however it is the first time running it under a new CMS system (Kentico MVC)
yes, the problem goes away with –api 2 added to the parameters (I removed the –live param)
three files are remaining in the first directory and none in the second, but that might be because the other directory (the CMS one) is not getting reached due to the LE64 process erroring out
all three files are different long unique names with no file extension
the problem remains regardless of whether or not I delete those orphaned files prior to the run
Thanks @mushu, I’ll have a look at the log when I’m back tomorrow and will get back to you. In the meantime, I would suggest switching to APIv2 - as you mentioned, that works fine and going forward (from the next version) this is going to be a default mode of running considering LE plans to deprecate v1. It will be still supported though to ensure that some users running the client against custom older ACME-supporting endpoints will still be able to use it.
Thanks @leader I appreciate that. For curiosity sake, what changed to make the old way not work? Was it due to me updating the server to a new O/S or perhaps locking out every protocol except TLS 1.2?
Hi @mushu, nothing changed from the client perspective, and the protocols in this case should not matter. I suspect that it might be something specific with the OS/setup, but in any case I’ll try to reproduce this closer to the weekend and, if I find that workflow may need to be changed anyhow, I’ll put that change into the next version.