Option -w will not used and set in registry

[oregano87]

Version 1.1.6

If I try use the parameter -c it will be ignored. Instead the DEFAULT Path will be used

My call WinCertes.exe -e admin@domain.test -d win.domain.test -b win.domain.test -w C:\inetpub\win

If I change this value in the registry it will be used but the HTTP challenge has an invalid status. The path will be created in the web directory but there is only a new file named "web.config" and there is no token file.

[aloopkin]

Hello,

Regarding the -w option, what happens if you delete its value from the registry, and then set it again from the command line?

For the rest, could you please:

1. delete all wincertes registry content
2. test again using the DEBUG version and against the LE Test directory (add -s https://acme-staging-v02.api.letsencrypt.org/directory)
3. post the results here

[oregano87]

Config in VS

After running the DEBUG version

If calling acme-staging of letsencrypt the token file will be written to the folder. But if I try my self hosted CA it does work. (Note, for this call I created a shortcut from wwwroot to win) In my linux environment with certbot there are no problems. So the CA is not the issue.

PS C:\Users\Administrator\Downloads\WinCertes-master\WinCertes-master\WinCertes\bin\Debug> .\WinCertes.exe -s https://pgwy.domain.test/acme/directory -w c:\inetpub\win -d win.domain.test -e admin@domain.org
[DEBUG] PFX password will be: 6f49badaa3294d20
[DEBUG] Successfully registered account admin@domain.org with certificate authority https://pgwy.domain.test/acme/directory
Successfully registered account admin@domain.org with certificate authority https://pgwy.domain.test/acme/directory
[DEBUG] Current certificate expiration date is: 
[DEBUG] Initiating HTTP Validation for win.domain.test
[DEBUG] Error while trying to register and validate order
System.Exception: HTTP challenge has an invalid status
   at WinCertes.CertesWrapper.<ValidateHTTPChallenge>d__18.MoveNext() in C:\Users\Administrator\Downloads\WinCertes-master\WinCertes-master\WinCertes\CertesWrapper.cs:line 253
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at WinCertes.CertesWrapper.<ValidateAuthz>d__16.MoveNext() in C:\Users\Administrator\Downloads\WinCertes-master\WinCertes-master\WinCertes\CertesWrapper.cs:line 193
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at WinCertes.CertesWrapper.<RegisterNewOrderAndVerify>d__15.MoveNext() in C:\Users\Administrator\Downloads\WinCertes-master\WinCertes-master\WinCertes\CertesWrapper.cs:line 157
[DEBUG] Failed to register and validate order with CA: HTTP challenge has an invalid status
Failed to register and validate order with CA: HTTP challenge has an invalid status

[aloopkin]

If it works with Let's Encrypt, then the issue isn't WinCertes, it's the Protocol Gateway... so you need to have it patched by R&D. "works with CertBot" doesn't mean "RFC 8555 fully compliant", not to mention that most ACME Clients implementation actually target Boulder and not RFC 8555.

At the end of the day, EverTrust TAP works to provide full ACMEv2 for CM... as well as other CAs ;-)