What Is the SSL Port? 443 Explained

The SSL port is 443: the standard TCP port for HTTPS, where web traffic travels encrypted with TLS. Its plaintext counterpart is port 80, where plain HTTP lives. When you load https://example.com with no port in the URL, the browser connects to 443; http:// goes to 80. The port itself adds no security; it is a convention about what protocol the server speaks there, which is exactly why mismatches between port and protocol cause some of the most common SSL errors.

Port 443 vs Port 80#

A production web server today listens on both, but 80 should do nothing except 301-redirect to 443 and answer certificate-renewal challenges. Serving real content on 80 splits your traffic into an insecure copy.

What Happens When You Connect to 443#

1. TCP connection opens to port 443
2. The client starts the TLS handshake, sending the hostname in clear text via SNI so the server can pick the right certificate
3. Server and client agree on a protocol version and cipher, and the server proves identity with its certificate
4. Encrypted HTTP flows inside the established session

When step 2 gets a plaintext HTTP response instead of a handshake, you get the port/protocol mismatch errors: SSL_ERROR_RX_RECORD_TOO_LONG in Firefox, ERR_SSL_PROTOCOL_ERROR in Chrome.

Other TLS Ports Worth Knowing#

443 is the web's TLS port, not the only one:

These are implicit TLS ports: the connection is encrypted from the first byte. The alternative pattern, STARTTLS, begins as plaintext on the service's classic port (SMTP on 25/587) and upgrades to TLS mid-conversation. Implicit TLS is the simpler and now generally preferred model.

Testing a TLS Port#

# Is something listening, and does it speak TLS?
openssl s_client -connect example.com:443 -servername example.com

# Non-default port, same idea
openssl s_client -connect example.com:8443

# STARTTLS services need the protocol named
openssl s_client -connect mail.example.com:587 -starttls smtp

# Is something listening, and does it speak TLS?
openssl s_client -connect example.com:443 -servername example.com

# Non-default port, same idea
openssl s_client -connect example.com:8443

# STARTTLS services need the protocol named
openssl s_client -connect mail.example.com:587 -starttls smtp

A completed handshake prints the certificate and negotiated protocol; a hang or garbage means the port is closed, filtered, or speaking something other than TLS.

Limitations to Know#

• Nothing enforces the convention. You can serve HTTPS on 8080 or plaintext on 443; the errors that follow are convention violations, not protocol failures.
• Firewalls only see the port. A network that "allows 443" allows whatever protocol someone runs there, which is why so much non-web tunneling rides 443.
• An open port is not a working service. 443 accepting TCP connections proves nothing about the certificate, the chain, or the app behind it.

Conclusion#

Port 443 is where HTTPS lives by convention: TLS handshake first, encrypted HTTP inside, with port 80 reduced to a redirect. The other TLS ports follow the same pattern for mail and directory services, and one openssl command tests any of them.

That last limitation is the operational trap: a port can accept connections while the service behind it fails every real request. ObserveOne checks the full path on your HTTPS endpoints, handshake included, not just whether 443 answers, so "the port is open but the site is down" stops being a blind spot.