webprofusion-chrisc
commented
3 years ago I'm don't know much about wincertes but Let's Encrypt HTTP validation only connects to port 80, it can then redirect to wherever you need to, but it will not begin http validation using any other port. This is standard for the ACME http-01 validation challenge.
What you need to do is either validate on port 80 (only possible with webservers that use http.sys, because they can share the port 80 http pipeline, nginx etc can't), or NAT external requests for TCP port 80 to port 81, or use DNS validation. If using DNS validation, any machine can get the cert then you just need to deploy it.
Describe the bug WinCertes fails HTTP Validation when using the --standalone and --listenport options. To anonymize this bug report I have replaced all instances of my actual domain name with "host.domain.com", and my email address with "user@gmail.com".
To Reproduce Steps to reproduce the behavior:
Expected behavior I would expect that a certificate be generated using port 81 instead of port 80.
Screenshots or Logs [DEBUG] PFX password will be: 795e62ba3b714d3d [DEBUG] Current certificate expiration date is: 03/14/2021 21:46:16 [DEBUG] Expiration Thresold Date after delay: 03/16/2021 11:44:34 [DEBUG] Started HTTP Listener on port 81 [DEBUG] Initiating HTTP Validation for host.domain.com [DEBUG] Error while trying to register and validate order System.Exception: Could not validate HTTP challenge: Fetching http://host.domain.com/.well-known/acme-challenge/gX-jm3CEjbL4SmEdzkGmcXI9gOu316ONpAEV2gKGtYM: Timeout during connect (likely firewall problem) at WinCertes.CertesWrapper.d16.MoveNext() in C:\Users\Alcide Loopkin\Source\Repos\WinCertes\WinCertes\CertesWrapper.cs:line 215
--- 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.d 15.MoveNext() in C:\Users\Alcide Loopkin\Source\Repos\WinCertes\WinCertes\CertesWrapper.cs:line 169
[DEBUG] Failed to register and validate order with CA: Could not validate HTTP challenge:
Fetching http://host.domain.com/.well-known/acme-challenge/gX-jm3CEjbL4SmEdzkGmcXI9gOu316ONpAEV2gKGtYM: Timeout during connect (likely firewall problem)
Failed to register and validate order with CA: Could not validate HTTP challenge:
Fetching http://host.domain.com/.well-known/acme-challenge/gX-jm3CEjbL4SmEdzkGmcXI9gOu316ONpAEV2gKGtYM: Timeout during connect (likely firewall problem)
[DEBUG] Just stopped the HTTP Listener
Output of "WinCertes --show": Service URI: https://acme-v02.api.letsencrypt.org/directory Account Email: user@gmail.com Registered: yes Auth. Mode: http-01 validation standalone HTTP Port: 81 IIS Bind Name: none Import in CSP: yes PS Script File: C:\Servers\RenewCerts.ps1 Renewal Delay: 21 days Task Scheduled: no Cert Enrolled: no
Desktop (please complete the following information):
Additional context I ran a copy of the nginx web server on port 81 on my computer to confirm that port 81 is accessible via the internet and through all firewalls. I used TCPView to verify that wincertes.exe is listening on port 81. As soon as I remove the --listenport option, causing wincertes.exe to use port 80, it works as expected. Based on the above log output, it appears that the port number is not being conveyed to the LetsEncrypt servers. Notice this line in the output does not include the port number: "Fetching http://host.domain.com/.well-known..." I would expect it to say "Fetching http://host.domain.com:81/.well-known..."