8443
Port 8443 · HTTPS alternate
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.
Find what is using port 8443
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.
- macOS
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.
- Linux
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.
- Linux
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.
- Windows
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.
- Windows
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.
Check it from outside the machine
`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.
Why a connection to 8443 fails
| 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. |
What runs on port 8443
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.
Should port 8443 face the internet?
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.
- Service
- HTTPS alternate
- Transport
- TCP
- Registry
- Not IANA assigned
- Category
- Web & HTTP
Tools on this site
All of these run in your browser — nothing is uploaded.
Related ports
Ports people usually end up checking in the same session as 8443.