I want to use Windows Admin Center, but I don't want to install a SSL certificate.
If I were to forward packets from 80 to 443 using firewall rules would they automatically be encrypted?
Add a comment
|
2 Answers
If I forward packets from 80 to 443 are they automatically encrypted?
No. You need to install a certificate for port 443 to encrypt anything.
Getting a certificate can be relatively easy with Let's Encrypt. And directions for installing one in Windows Admin Center are easily found.
-
That's not technically true. You need a certificate for HTTPS with a browser, but I could run an SSH server on 443 and accept SSH connections - which use encryption, but do not use certificates - at that port just fine. There's approximately no reason to ever do this, but you could. Also, you don't actually need a certificate for TLS (the secure protocol that underlies HTTPS; HTTPS is just HTTP via TLS); TLS can use pre-shared keys or Secure Remote Password for authentication, or be entirely unauthenticated. Browsers don't support any of those modes, but other clients do. Mar 5 at 19:43
-
Also, you say "for port 443 to encrypt anything" but ports don't do encryption! That's entirely up to the application-layer protocol that the client and server are speaking over that port, and any protocol can be used for any port (and any port with any protocol). Mar 6 at 6:02
-
You seem to be mistaking a world full of perverted thing you can do with arbitrary ports and arbitrary protocols, and the fact that to OP just wanted to know whether he needed to set up HTTPS. Mar 6 at 16:10
You seem maybe a bit confused about how networking works. TCP port 443 is just another network endpoint on your host. It is merely convention that it's used for HTTTPS; you can use HTTPS on any port, and you can use any protocol (including plain-text ones) on 443. For example, https://example.com:80/ is a legal URL (aside from using a reserved domain) that will attempt to connect via a TLS (secure, encrypted) connection to port 80. http://example.com:443/ is the opposite; an insecure connection made to port 443. You can also point HTTP or HTTPS at arbitrary other ports, such as 22 (usually used for SSH, which is a secure protocol but completely separate from HTTPS/TLS) or 5823 (a random keyboard-smash of a port that, as far as I know, no particular program or protocol uses). Similarly, you can point an SSH client at port 80, 443, or any other, should you wish to.
Of course, in all these cases, it doesn't do any good to attempt a connection to that port unless there's a server listening on it that speaks the same protocol. If there isn't, the connection attempt will either be ignored, or either the client or server will quickly notice an unexpected failure to observe the expected protocol, and break the connection. Note that for this purpose, HTTP, HTTPS, SSH, FTP, RDP, etc. are all different, incompatible protocols.
