You can't port forward one [external] IP:port to two [internal] IPs:port.
3 Likes
As far as I'm aware, uninstalling IIS doesn't actually stop the core http.sys system service from running and using port 80 by default. It's sort of like how you can't really uninstall Internet Explorer.
4 Likes
Sorry, I believe you misunderstood me. I Port Forwarded two different Ports (80 and 443) to the same Internal Fixed LAN IP Address. I do that all the time and my Synology NAS that had the hardware failure wouldn't have performed properly if I didn't do that. I do the same for Email Ports for my Email Server.
1 Like
OK, so where are they forwarding to now?
2 Likes
That doesn't seem entirely accurate to me because if you have two or more Windows computers in the same Local Network that both listen on Port 80 as you've implied then you wouldn't be able to Port Forward to 80 to all those Windows computers. I do understand that possibly Port 80 would be outgoing and NAT would then allow the associated Incoming response on Port 80 to all those computers but that isn't Port Forwarding. If I understood Certbot for Windows correctly. I believe Certbot used outgoing Port 80 to send the CSR to Let's Encrypt and then returned the Certificates through Port 443. Although I used the 'standalone' option, if the '--webroot' option had been selected, Certbot would have stopped the webserver so it could process the Certificate Request and install it into the Webserver. I can see in the Certbot Log where Certbot appears to do a 'Post' using Port 443 to do the return and gets a successful response on these operations. It is only when Certbot attempts to do the Challenges for authentication that Certbod seems to issue the exception error noting that it failed to Bind to Port 80 citing the Socket Permissions were not correct. The 'standalone' option tells Certbot to not stop the Webserver and use a temporary webserver it creates to process the CSR and it tells Certbot to not install it in the Webserver.
Ports (80 and 443) are Port Forwarded from the Router to the Windows computer that runs the Email Server and the Certbot for Windows utility in the Local Network.
Not exactly.
certbot reaches out to the CA [via port 443] and negotiates what file it needs to place into which location [DNS or HTTP] to satisfy the authentication request.
Without closing that call, the CA makes a request to that system [authoritative DNS, or HTTP to FQDN, or HTTPS(ALPN) to FQDN] and verifies the file is there. If so, then the CA will issue a cert and the certbot client will retrieve it via that ongoing connection [via port 443].
2 Likes
OK, so, one single computer [that runs email and certbot] using Windows.
certbot for Windows is NOT a very advanced Windows software.
[it's a port from Linux and has much to be desired]
Since you have removed IIS, I would recommend using another ACME client for Windows.
OR
If you can somehow use some other system [for the inbound HTTP requests only]...
You could use that to proxy the challenge requests to the mail server on any other (unused/open) port.
[and proxy any/all other HTTP requests to wherever that need to go]
2 Likes
The reason I would be revoking the Certificate created by the Win-ACME (WAACS) is because it is in a useless format for me. I need .PEM files not the file format it produced though Win-ACME is supposed to be capable of providing .PEM format files. It's just that I would have to probably do a lot of research to be able to make Win-ACME work. I do understand there may be some scripts on Github that would take care of that for me but I would have to hunt for them. I'm also concerned about possible Let's Encrypt restrictions on too many Certificate requests. It seems the easiest thing to do would be to Revoke the useless Certificate unless there is a way to convert it into .PEM files and then I would really like to also get them into Ecliptic Curve Certificates if possible which Win-ACME is also supposed to be able to produce if I remember correctly.
Then you need to read on the acceptable reasons to revoke certificates.
That isn't one of them.
See: Revoking Certificates - Let's Encrypt (letsencrypt.org)
And to make it perfectly clear: Revoking a cert doesn't undo it in any way - it won't remove the fact that it was issued [that happened] and it won't undo the counter of that issuance [that also happened].
It only makes it very insecure for anyone to use it from that point forward.
3 Likes
Thanks for the link. I knew there were the conditions you were referring to and was first going to check those conditions before attempting to Revoke the Certificate.
2 Likes
Then that would be the 'Get' that was performed on the Lets Encrypt API using Port 443. I do see where it prepares the Cert and 'Post' into the API again on Port 443. This would also be where it processes the "HEAD" . But there is no actual explicit use of Port 80 in the Certbot Log and I would assume that takes place through Port 80 when it processes the Challenges and that is where it fails and issues the Bind Error messages about Port 80.
From here: Challenge Types - Let's Encrypt in the HTTP-01 challenge section
"
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
The HTTP-01 challenge can only be done on port 80. Allowing clients to specify arbitrary ports would make the challenge less secure, and so it is not allowed by the ACME standard.
"
1 Like
Regarding win-acme you can try their pemfiles option to get the files you need. win-acme
Regarding http.sys still using port 80 (and blocking certbot), try running netsh http show servicestate from an administrative command prompt, this should show registered listeners and if any of those are actually running on port 80 then they will be (part of) what's consuming port 80. Stopping the associated services should free that up.
Meanwhile, for anyone with similar requirement here is also how you'd get a PEM file using Certify The Web (which I develop and can therefore comment more easily on) using the default http challenge handler (which will peacefully share with other http.sys listeners like IIS etc):
- install the the app from https:///certifytheweb.com
- click New Certificate, you will also be prompted to set up a Let's Encrypt account.
- In the certificate tab, add the domains you need on your certificate
- under Authorization you can stick with the default http challenge response, or use DNS validation if you prefer (if your DNS provider is supported).
- click "Test" to do a basic check on your configuration, then "Request Certificate" to perform a certificate order.
- If that all works ok you will now have a valid certificate to work with.
- You can now get PEM file output by adding a Deploy to Generic Server task under Tasks (deployment tasks). Under Task Parameters set the output file paths and file names you need. Save the managed certificate settings then click the Play button next to the task, your certificate will then be converted and saved using the options you selected in the task. Future automated renewals will update these files.
- Consider what other steps you could then automated, for instance if you need these files on a remote linux server that supports ssh, update or add another task with the required settings set to deploy to that host (the above task supports ssh/sftp deployment).
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.