8443
The unprivileged twin of 443: TLS on a port an ordinary user can bind, and the number Tomcat and most appliance admin consoles reach for.
Run the line for your platform. Each one names the process holding the port and the address it bound to, which is usually the whole answer.
sudo lsof -nP -iTCP:8443 -sTCP:LISTEN`-n` and `-P` keep hosts and ports numeric, `-iTCP:8443` selects the port and `-sTCP:LISTEN` selects the listening state — the pairing lsof's manual uses as its own example. The PID is the second column and the bind address is the last, shown as `127.0.0.1:8443 (LISTEN)` or `*:8443 (LISTEN)`. A loopback bind is the usual reason a colleague cannot reach the console you can see. If the COMMAND column reads `java`, you are almost certainly looking at a Tomcat or another application server; stop the service rather than the process where you can. Add `sudo` or you will only see listeners owned by your own user, and lsof exits 1 with no output when the port is free.
sudo ss -tlnp 'sport = :8443'Per the ss(8) manual, `-t` displays TCP sockets, `-l` only listening ones, `-n` leaves service names unresolved and `-p` shows the owning process; `sport = :8443` is the documented port filter form. The Local Address:Port column is the answer to "why can nobody else reach it": `127.0.0.1:8443` is this machine only, `0.0.0.0:8443` is every IPv4 address, and `[::]:8443` is the IPv6 wildcard that usually covers IPv4 too. The process shows as `users:(("java",pid=4310,fd=52))`. Where `ss` is missing, `netstat -tlnp` prints the same columns, and both need root before they will name a process you do not own.
openssl s_client -connect host.example.com:8443 -servername host.example.comThe probe that answers a different question: not who holds the port, but whether it is really TLS. `-connect host:port` chooses the target and `-servername` sends the SNI extension, which a virtual-hosted server needs before it will present the right certificate. A successful run prints the certificate chain, the negotiated protocol and cipher, and then waits for input. A handshake that fails immediately means the listener is speaking something else — try `curl -v http://host.example.com:8443/` and see whether plain HTTP answers. Add `-showcerts` when you need the full chain to work out which intermediate is missing.
netstat -ano | findstr :8443Microsoft documents `-a` as displaying all active connections and the ports the computer is listening on, `-n` as expressing addresses and ports numerically, and `-o` as including the process ID for each connection. Read the Local Address column for the bind address, the State column for LISTENING, and the final column for the PID; resolve that with `tasklist /fi "PID eq 4310"`, using the documented `PID` filter and its `eq` operator. `findstr` matches a substring anywhere in the line, so an established outbound connection to some other host on 8443 shows up in the same output — the State column is what separates the two.
Get-NetTCPConnection -LocalPort 8443 | Select-Object LocalAddress,LocalPort,State,OwningProcessThe PowerShell equivalent, matching the port numerically instead of by text, so it cannot pick up a `:8443` that happens to appear elsewhere on the line. `Get-Process -Id` on the `OwningProcess` value gives the executable. If this returns nothing and your server still cannot bind, the port is reserved rather than occupied — `netsh interface ipv4 show excludedportrange protocol=tcp` lists the ranges Hyper-V, WSL2 and Docker Desktop reserve at boot, and anything inside them fails to bind with no owner to find.
`nmap -Pn -p 8443 app.example.com` tells you what the port looks like from outside the host, which is often the opposite of what it looks like on it. `-Pn` skips host discovery and treats the target as online; `-p` restricts the scan to the one port. `open` means the handshake completed and something is listening. `closed` means the host answered with a reset, so it is reachable and nothing holds the port — that is what you see when the TLS connector was never uncommented. `filtered` means the probe vanished with no answer, which is a firewall or security group dropping it. `--reason` shows which of the three it was: `syn-ack` for open, `conn-refused` for closed. `-sV` probes the open port to determine service and version information, and it is the fastest way to learn whether the thing on 8443 is speaking TLS at all or just plain HTTP on a suggestive number. Scan only hosts you are responsible for.
| What you see | What it means |
|---|---|
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version | curl exit code 35 is a TLS handshake failure, and the wording after it depends on which TLS library curl was built against — OpenSSL builds report a different line for the same event. The cause is nearly always that you asked for `https://` and the listener on 8443 is speaking plain HTTP. Confirm it by fetching `http://host:8443/` instead; if that returns a page, the port is fine and the scheme was wrong. |
The browser shows ERR_SSL_PROTOCOL_ERROR | Chromium's name for network error -107, `SSL_PROTOCOL_ERROR`, and the browser-side version of the failure above: something answered, but not with a TLS handshake the browser could complete. Try the same URL with `http://`. If plain HTTP works, the service is not configured for TLS on this port, whatever the number implies. |
NET::ERR_CERT_AUTHORITY_INVALID | Chromium error -202, `CERT_AUTHORITY_INVALID`. This is good news about the port: TLS is working and a certificate was presented, it simply does not chain to a root this machine trusts — a self-signed certificate, or a private CA that was never installed. Nothing about the network needs changing; decode the certificate and decide whether to trust its issuer. |
Connection refused on 8443 while 8080 on the same host works | The classic Tomcat shape. Its shipped `server.xml` leaves the 8443 TLS connector commented out while the active connector on 8080 still advertises `redirectPort="8443"`, so anything marked as requiring a secure channel redirects the browser to a port nobody is listening on. Uncomment and configure the TLS connector, or change `redirectPort`. |
Error: listen EADDRINUSE: address already in use 0.0.0.0:8443 | Another process already holds the port. Because 8443 attracts management interfaces, the occupant is often something installed rather than something you started — an appliance agent, a previous run of the same server, or a container still publishing the port. Find the owner with the probe for your platform before killing anything. |
It works on the server itself but times out from anywhere else | Two candidates, and the probes separate them in one line. Either the listener bound to `127.0.0.1` instead of a routable address, in which case the local-address column says so, or a firewall is dropping the SYN, in which case nmap reports the port `filtered` rather than `closed`. A timeout is a drop; a refusal is instant. |
8443 is a convention, not an assignment. The IANA registry does list the number, but against `pcsync-https`, 'PCsync HTTPS', which has nothing to do with the way the world actually uses it — so calling 8443 'the registered HTTPS alternate' is wrong on the registry's own terms. What made the number stick is the arithmetic that made 8080 stick: on Unix systems ports below 1024 are privileged, so a server that wants TLS without running as root takes 443 and adds 8000. Apache Tomcat is the clearest case. The `server.xml` it ships sets `redirectPort="8443"` on the plain connector that listens on 8080, and carries a TLS connector for 8443 in the same file — commented out, with a sample keystore. So a Tomcat that bounces you to `https://host:8443/` is doing exactly what its default configuration says, whether or not anybody uncommented the listener. Nothing about the number itself implies encryption. A browser decides whether to speak TLS from the URL scheme, not from the port, so `https://host:8443/` is an ordinary HTTPS request to an unusual port and `http://host:8443/` is an ordinary plaintext one — which is why the most common failure on this port is a scheme and a listener that disagree with each other.
Two separate questions hide behind 'is 8443 safe'. The first is whether TLS is actually there. The number promises nothing, and a service answering plain HTTP on 8443 is exactly as readable on the wire as one on 8080, so check instead of assuming: `openssl s_client -connect host:8443 -servername host` either completes a handshake and prints the certificate chain, or fails immediately and tells you the listener is not speaking TLS. The second question is what sits behind it, and this is where the port earns its reputation. What ends up on the unprivileged HTTPS port is disproportionately management surface — application-server consoles, appliance web UIs, build servers, monitoring and sidecar endpoints — things written on the assumption that only an operator would find them. Scanners sweep 8443 exactly as they sweep 443, so an unusual number buys no obscurity at all. If a service is meant for the public, terminate TLS once on 443 at a proxy holding a real certificate. If it is a management interface, do not route it from the internet: bind it to a private address, put it behind a VPN or an identity-aware proxy, and restrict source addresses at the firewall. Self-signed certificates are common here because the port is so often internal — decide deliberately whether you are verifying that certificate or clicking past the warning, because clicking past it looks identical to clicking past an interception.
All of these run in your browser — nothing is uploaded.
Ports people usually end up checking in the same session as 8443.
Almost always permissions. lsof and ss list the socket but hide the owning process when it belongs to another user, so a server started by a system account, by a container runtime or by launchd shows up as an anonymous listener until you re-run the command with sudo. On Windows the opposite happens: netstat shows nothing at all, yet a bind still fails, which means the port sits inside a range that Hyper-V, WSL2 or Docker Desktop reserved at boot.
Look at what it is first. An orphaned dev server is safe to kill; a database with a write in flight is not, and neither is a system service that something else depends on. If the owner is a container, stop the container instead — killing the process the host sees only makes the runtime restart it. When the process is something you need, moving your own service to another port is the faster fix.
The listener bound to 127.0.0.1 rather than 0.0.0.0. The probes on every page print the bound address next to the process for exactly this reason: a loopback bind is reachable from the machine itself and from nowhere else, no matter how the firewall is configured. Many frameworks made that the default deliberately, so it is usually a flag rather than a bug. If the address is already 0.0.0.0 and it still fails, the next suspect is a host firewall or a cloud security group.
Barely. Internet-wide scanners sweep the whole port range continuously, so an unusual number buys hours, not safety, and it costs you every colleague who now has to remember it. It does cut the noise in your logs from opportunistic scans of the default port, which is a real if modest benefit. Authentication, a firewall that restricts source addresses, and not exposing the service at all are the measures that actually change the outcome.
Still stuck on port 8443? browse every port in the reference — or go back to the failure message you actually got, above.