What Is a TLS/SSL Port? A Guide to Secure Ports for IT Teams

Published: January 2023. Updated: August 2026. Reviewed by Encryption Consulting’s PKI Advisory team.

Every network connection needs a destination, and a port number is how a system tells its network stack which service should handle incoming traffic on a given IP address. Web traffic on port 80 is unencrypted HTTP; the moment that same traffic needs to be encrypted, it typically moves to port 443 and becomes HTTPS. The same pattern repeats across mail, directory, and file transfer services: each has a plaintext port and a corresponding TLS/SSL port (or a TLS upgrade path on the same port) reserved for encrypted traffic.

This guide covers the common TLS/SSL ports IT and network teams actually configure, how TLS negotiation differs between them (implicit TLS versus STARTTLS/explicit TLS), how to choose the right port and mode for a given protocol, the threat model specific to these ports, a numbered hardening process, the performance and interoperability trade-offs involved, and the certificate and key-management dependencies every one of these ports carries. For the mechanics of the TLS handshake itself and which cipher suites to run, see our companion guide, An Introduction to Cipher Suites; for diagnosing a handshake that is already failing on one of these ports, see How to Fix the SSL Handshake Failed Error.

What Is a TLS/SSL Port?

A TLS/SSL port is the network port a protocol uses specifically for its encrypted variant, distinct from the plaintext port the same protocol uses by default. There are 65,535 TCP and UDP ports in total, but IANA maintains an official registry (the Service Name and Transport Protocol Port Number Registry) that assigns a standard name and description to the ports actually in common use, including the TLS/SSL variant of each major protocol. Port 443 is registered as “http protocol over TLS/SSL,” which is why HTTPS traffic defaults there; port 636 is registered for “ldapssl,” the encrypted form of LDAP; and so on for mail and file transfer.

Technically, SSL (Secure Sockets Layer) is the deprecated predecessor to TLS (Transport Layer Security). Every port described in this guide as an “SSL port” now negotiates TLS, most commonly TLS 1.2 or TLS 1.3 as defined in RFC 8446, the TLS 1.3 specification. The industry kept the “SSL” name in port labels (HTTPS, LDAPS, IMAPS) for historical continuity, and both terms are used interchangeably in this guide for that reason, as covered in our TLS/SSL education center article.

What Are the Common TLS/SSL Ports and Which Protocols Use Them?

The table below covers the TLS/SSL ports an IT or network team encounters most often, each protocol’s plaintext counterpart, and whether that port uses implicit TLS (encrypted from the first byte) or explicit TLS (starts in plaintext, then upgrades via a command such as STARTTLS). All port and service name assignments below come from the IANA Service Name and Transport Protocol Port Number Registry unless a specific RFC is cited.

Port	Protocol / Service	TLS Mode	Typical Use
443	HTTPS (HTTP over TLS)	Implicit	Encrypted web traffic, REST/API endpoints, most browser traffic
465	SMTPS / “submissions” (Message Submission over implicit TLS)	Implicit	Mail client submitting outgoing mail to a mail server, per RFC 8314
587	SMTP Message Submission	Explicit (STARTTLS)	Mail client submitting outgoing mail; the long-standing default, defined in RFC 6409 and updated by RFC 8314
993	IMAPS (IMAP over TLS)	Implicit	Mail client retrieving mail via IMAP
995	POP3S (POP3 over TLS)	Implicit	Mail client retrieving mail via POP3
636	LDAPS (LDAP over TLS)	Implicit	Directory service binds and lookups (Active Directory, OpenLDAP)
989 / 990	FTPS data / control (implicit)	Implicit	Legacy implicit FTPS, a pre-standard convention still supported by most FTPS servers
21	FTP with AUTH TLS (explicit FTPS)	Explicit (AUTH TLS)	FTP control channel upgraded to TLS via the RFC 4217 AUTH TLS command

How Does TLS Negotiation Happen on These Ports? Implicit TLS vs. STARTTLS

TLS negotiation on these ports happens one of two ways: implicit TLS, where the TLS handshake begins the instant the TCP connection opens, before any application protocol data is exchanged; or explicit TLS (commonly called STARTTLS), where the connection starts in plaintext using the normal protocol and only upgrades to TLS after the client sends a specific command and the server agrees.

Implicit TLS

On an implicit TLS port such as 443, 465, 993, 995, 636, or 990, the server expects a TLS Client Hello as the very first bytes on the connection. There is no plaintext phase to strip or intercept, because no protocol command is exchanged before encryption starts. RFC 8314, which formalized implicit TLS for mail protocols, states this plainly for POP3S and IMAPS: a TLS handshake begins immediately once the connection is established, and clients must validate the server’s certificate before proceeding. This is why RFC 8314 now recommends implicit TLS as the preferred mode for POP, IMAP, and SMTP submission going forward, reversing the industry’s earlier preference for STARTTLS.

Explicit TLS (STARTTLS)

On an explicit TLS port such as 587 for SMTP or 389 upgraded for LDAP, the connection begins as a normal plaintext session. The client issues a protocol-specific command (STARTTLS for SMTP, IMAP, and POP3; AUTH TLS for FTP under RFC 4217), the server responds that it is ready, and only then does the TLS handshake begin on that same TCP connection. RFC 3207, the SMTP STARTTLS extension, defines this mechanism for SMTP specifically and notes that “STARTTLS is a valid ESMTP extension when used on the Submission port,” meaning STARTTLS on port 587 is standards-compliant, not a workaround. After a successful STARTTLS upgrade, the protocol state resets and the client must reissue its initial handshake command (EHLO for SMTP) inside the new encrypted channel.

The trade-off is that the plaintext phase before the upgrade is an exposed window. RFC 3207 itself documents the core risk: an attacker positioned on the network path can delete the server’s “250 STARTTLS” response before it reaches the client, causing the client to silently continue in plaintext instead of failing the connection, a class of attack the industry now calls STARTTLS stripping. A 2021 academic study, “Why TLS Is Better Without STARTTLS: A Security Analysis of STARTTLS in the Email Context” (Poddebniak et al., USENIX Security), found dozens of STARTTLS command injection vulnerabilities across widely used mail clients and servers, where a MITM could inject commands into the plaintext buffer before the TLS handshake completed. This research is a direct reason RFC 8314 now pushes implicit TLS as the safer default for new deployments, while STARTTLS on 587 remains standards-compliant and widely deployed for compatibility.

How Do You Choose the Right Port and TLS Mode for a Protocol?

Choose the implicit TLS port for a protocol whenever both the client and server support it, since it removes the plaintext negotiation window entirely; fall back to the explicit/STARTTLS port only when a client, a legacy mail relay, or a compliance requirement genuinely cannot use implicit TLS. In practice, the decision looks different by protocol:

• Web traffic: use port 443 (implicit) exclusively. There is no widely deployed explicit-TLS equivalent for HTTP; redirect all port 80 traffic to 443 rather than negotiating TLS on 80.
• Mail submission (client to server): prefer port 465 (implicit, “submissions”) for new mail client configurations per RFC 8314. Keep port 587 (STARTTLS) available for older clients and for compatibility with mail software that still defaults to it; never allow unauthenticated relay on port 25 in either mode.
• Mail retrieval (IMAP/POP3): use the implicit ports, 993 and 995, exclusively where possible. Both protocols also support STARTTLS on their plaintext ports (143 and 110), but there is little remaining reason to prefer that path given current client support for the implicit ports.
• Directory services (LDAP): use port 636 (LDAPS, implicit) for external and cross-network binds. StartTLS on port 389 is still supported by Active Directory and OpenLDAP and is sometimes required for compatibility with tools that only speak plaintext LDAP with an upgrade, but 636 avoids the upgrade window entirely.
• File transfer: if you control both endpoints, prefer SFTP (SSH File Transfer Protocol, a completely different protocol running over SSH) over FTPS entirely, since it avoids the FTP control/data channel complexity described below. Where FTPS is required for compatibility, implicit FTPS on 990/989 is simpler to firewall than explicit FTPS’s AUTH TLS upgrade on port 21, because the TLS boundary is fixed at connection time rather than negotiated mid-session.
• Custom or internal services: TLS is transport-agnostic and can run on any port; if a service is TLS-protected but not one of the ports above, it must be documented in firewall rules and client configuration explicitly, since neither party can assume implicit or explicit behavior from an unregistered port number.

What Firewall and Network Configuration Considerations Apply to TLS/SSL Ports?

Firewall rules for TLS/SSL ports need to account for both directions of traffic and for the fact that a TLS port and its plaintext counterpart are functionally different services that happen to share a protocol name. A few considerations recur across most environments:

• Block plaintext ports at the network edge where possible. If a service is meant to be reached only over TLS, blocking inbound traffic to its plaintext port (80, 143, 110, 389, 21 without a TLS requirement) at the perimeter firewall removes an entire class of accidental cleartext exposure, rather than relying on every client to choose the encrypted port correctly.
• Explicit/STARTTLS ports still need to stay open for the initial plaintext phase. Blocking port 587 or 389 outright breaks STARTTLS entirely, since the upgrade command has to be sent on that same port before encryption begins; the correct control here is enforcing mandatory TLS on the server side (rejecting any session that never upgrades), not blocking the port.
• FTPS needs a data channel port range, not just the control port. Explicit FTPS on port 21 and implicit FTPS on port 990 both still negotiate a separate data connection, historically port 989 for implicit mode or a dynamic passive-mode range for explicit mode; firewall rules must open that data range too, or file transfers will authenticate successfully and then fail to move data.
• Middleboxes and proxies can silently break TLS negotiation on any of these ports. Deep packet inspection appliances, corporate TLS-inspecting proxies, and SNI-based routing all need to recognize the specific port and TLS mode in use; a proxy that strips the STARTTLS command or fails to forward SNI produces a handshake failure that looks identical to a certificate problem, which is why diagnosis (see our SSL handshake troubleshooting guide) should isolate the network path before assuming a certificate issue.

What Is the Threat Model for TLS/SSL Ports?

The threat model for TLS/SSL ports covers three distinct risks: reconnaissance through port scanning, protocol downgrade on the wrong port or TLS mode, and the certificate and configuration failures that make an otherwise correctly chosen port insecure in practice.

• Port scanning and service fingerprinting. Tools like nmap and internet-wide scanners such as Shodan or Censys routinely enumerate which ports respond on a given IP and fingerprint the TLS version, cipher suite, and certificate each one presents. Moving a service to a nonstandard port does not meaningfully reduce this exposure; it only adds friction for legitimate clients while a determined scanner still finds the open port. The real control is minimizing which ports are open at all and hardening what each open port actually negotiates.
• Protocol downgrade on explicit/STARTTLS ports. As covered above, an attacker positioned on the network path can strip the STARTTLS response on port 587 or the equivalent upgrade command on port 389 or 21, forcing the session to continue in plaintext or fall back to a weaker cipher suite the attacker can break. RFC 3207’s security considerations section documents this directly for SMTP, and the 2021 USENIX STARTTLS research demonstrated working command-injection variants of the same attack across multiple mail clients and servers.
• Wrong port, wrong assumption. A common operational mistake is assuming a listening service is encrypted because it is bound to a port conventionally associated with TLS (443, 465, 993), without verifying the certificate is valid, the chain is complete, and the negotiated cipher suite is actually strong. The port number is a convention, not a guarantee; use openssl s_client -connect host:port -servername host against each of these ports to confirm what is actually negotiated, not just what the port number implies.

How Do You Configure and Harden a TLS/SSL Port?

Configuring and hardening a TLS/SSL port is a repeatable process regardless of which protocol is involved:

1. Inventory every currently listening port on the host or network segment with a scanner such as nmap, and confirm which ports are actually needed versus inherited from a default install.
2. Prefer the implicit TLS port for each protocol where client support allows it (443 for web, 465 for mail submission, 993/995 for mail retrieval, 636 for LDAP, 990 for FTPS), and reserve the explicit/STARTTLS port only for documented legacy compatibility.
3. Enforce mandatory TLS on any explicit/STARTTLS port that must stay open, rejecting sessions that never upgrade rather than silently allowing plaintext fallback (in Postfix, for example, this is smtpd_tls_security_level = encrypt rather than the default opportunistic setting).
4. Restrict TLS versions and cipher suites on every port to TLS 1.2 and TLS 1.3 with AEAD-only cipher suites; see our cipher suites guide for the specific suite list by scenario.
5. Install the full certificate chain, leaf plus intermediate, on every TLS-terminating port; an incomplete chain fails validation for any client that does not already cache the missing intermediate.
6. Configure firewall rules per port: block plaintext ports at the perimeter where the service is meant to be TLS-only, and open the correct data-channel range alongside any FTPS control port.
7. Test every port directly with openssl s_client -connect host:port -servername host -starttls <protocol> (OpenSSL supports a -starttls flag for smtp, imap, pop3, ldap, and ftp) to confirm the negotiated protocol version, cipher suite, and certificate chain match what was configured.
8. Monitor certificate expiry and renewal across every TLS port continuously, since a lapsed certificate fails the handshake on that port regardless of how well everything else is configured.

What Are the Performance and Interoperability Trade-Offs?

Implicit TLS ports generally perform better and are simpler to reason about, but explicit/STARTTLS ports remain necessary for interoperability with clients, mail relays, and network appliances that were built around the plaintext-first model:

• Round trips. Implicit TLS begins the handshake immediately, so the connection reaches encrypted, authenticated state in the minimum number of round trips the TLS version allows (one round trip under TLS 1.3). STARTTLS adds the plaintext command/response exchange before the handshake even starts, which is a measurable latency cost on high-volume mail relay traffic, though usually negligible for a single interactive session.
• Middlebox compatibility. Some older enterprise firewalls, mail gateways, and monitoring appliances were built to inspect plaintext SMTP, LDAP, or FTP traffic and only later added STARTTLS awareness; a hard cutover to an implicit-TLS-only port can break that inspection tooling until it is reconfigured or replaced, which is a real migration cost worth planning for rather than an argument against making the change.
• Client and server software age. Legacy mail clients, embedded devices, and some line-of-business software still default to the STARTTLS ports (587, 389, 21) because that is what their configuration UI exposes; migrating them to implicit ports may require an explicit configuration change rather than happening automatically, so a phased rollout with both ports available during transition is the realistic path for most organizations, matching the “broad public-facing compatibility” guidance in our cipher suites article.

What Key-Management Dependencies Do TLS/SSL Ports Have?

Every TLS/SSL port, implicit or explicit, ultimately depends on a valid certificate and its corresponding private key being available to the service at the moment a client connects. That dependency has several practical implications:

• One certificate can cover multiple ports on the same host if the Subject Alternative Name entries match the hostnames each port serves, but a server hosting multiple distinct hostnames behind one IP needs Server Name Indication (SNI) to present the correct certificate per connection, since the client’s requested hostname has to reach the server before the right certificate can be selected, as explained in Cloudflare’s explanation of how SNI works.
• Renewal has to reach every port that certificate serves. A certificate shared across a web server on 443, a mail submission agent on 465/587, and an LDAP directory on 636 has to be redeployed to all three services on renewal; missing one is a common cause of a handshake failure on only one port while the others continue working.
• HSM-backed keys add availability as a dependency. If the private key for a TLS-terminating service is held in a hardware security module rather than on local disk, the service depends on that HSM being reachable to complete the handshake (for key exchange algorithms that require a live signing operation) or, for ECDHE-based suites, at minimum to hold the certificate’s signing key available for the authentication step; an HSM outage can produce handshake failures that look identical to a certificate problem.
• Certificate key type has to match what each port’s client population supports. As covered in our cipher suites guide, ECDSA and RSA certificates are not interchangeable at the cipher suite level; a directory service on 636 or a mail server on 465/587 serving an older client population may need an RSA certificate specifically, even if a newer web service on 443 has already moved to ECDSA.

What Do Real Deployments of These Ports Look Like?

• Web server (443): Nginx or Apache terminates TLS on port 443 using a certificate issued through an internal CA or a public CA, with HTTP on port 80 configured only to issue a 301 redirect to the HTTPS URL rather than serving content in the clear.
• Mail submission (465/587): Postfix listens on both 465 (implicit, smtpd_tls_wrappermode = yes) and 587 (STARTTLS, smtpd_tls_security_level = encrypt) to support both modern mail clients configured for implicit TLS per RFC 8314 and older clients still configured for STARTTLS, while port 25 stays restricted to authenticated relay or server-to-server delivery only.
• Mail retrieval (993/995): Dovecot binds its IMAP and POP3 listeners to the implicit ports 993 and 995 with ssl = required, and disables the plaintext 143/110 listeners entirely for external access.
• Directory service (636): OpenLDAP or Active Directory Lightweight Directory Services is configured with an ldaps:// listener on 636 bound to a certificate whose Subject Alternative Name matches the directory’s fully qualified domain name, alongside StartTLS on 389 kept available only for internal tooling that has not yet migrated.
• File transfer (989/990 or 21): A vsftpd or ProFTPd server offers implicit FTPS on control port 990 with its data channel on 989 for clients that support it, and explicit FTPS via AUTH TLS on port 21 for older FTP clients, with both modes requiring the same certificate and disabling anonymous plaintext FTP entirely.

Limitations

• This guide covers the common TLS/SSL ports IT and network teams configure most often; it is not an exhaustive list of every IANA-registered TLS port (NNTPS on 563 and other less common protocols exist but are omitted here for focus).
• Port assignments describe convention, not enforcement; nothing prevents a service from running TLS on a nonstandard port, and firewall and client configuration must document any such deviation explicitly.
• The firewall guidance here is general; specific cloud provider security groups, next-generation firewalls, and compliance frameworks (PCI DSS, FIPS 140-3, FedRAMP) may impose additional port and protocol restrictions that should be validated against your environment’s specific requirements before deployment.
• This guide assumes standard TCP-based TLS; QUIC and HTTP/3 (which run over UDP port 443) use a different handshake process and are outside its scope.

What Would Encryption Consulting Recommend?

We would treat every TLS-terminating port in your environment as one certificate inventory, not a set of independent configurations to track by hand. In practice, most organizations we work with can list their web servers’ certificates without difficulty but lose visibility fast once mail submission agents, directory services, and FTPS endpoints are added to the picture, and a certificate lapsing quietly on port 636 or 465 produces the same production outage as one lapsing on 443. CertSecure Manager discovers certificates across every TLS-terminating service in your environment, whichever port and protocol it runs on, monitors expiry and chain completeness continuously, and automates renewal and redeployment so a handshake never fails on any of these ports because a certificate quietly expired. For organizations designing or hardening the certificate authority infrastructure that issues those certificates in the first place, including the key-type and HSM-backed key strategy that has to match the cipher suites and client population each port serves, our PKI Services team builds and hardens that CA hierarchy end to end.

Frequently Asked Questions

What port does TLS/SSL use? There is no single TLS/SSL port; each protocol has its own. Port 443 is the default for HTTPS, but mail, directory, and file transfer services each use a different registered TLS port, such as 465 or 587 for mail submission, 993 for IMAPS, and 636 for LDAPS.

Should I use port 465 or 587 for SMTP? Prefer 465 (implicit TLS) for new mail client configurations, since RFC 8314 now recommends implicit TLS for mail submission and it removes the plaintext negotiation window entirely. Keep 587 (STARTTLS) available for compatibility with mail software and clients that still default to it; it remains a fully standards-compliant configuration under RFC 3207 and RFC 6409.

Can TLS run on any port, or only the registered ones? TLS is transport-agnostic and can run on any port a service is configured for. The registered ports (443, 465, 587, 993, 995, 636, 989/990) exist purely as convention so clients and firewalls know what to expect by default; a service on a nonstandard port works identically but requires explicit configuration on both the client and any firewall rule involved.

What is the difference between implicit and explicit TLS? Implicit TLS begins the TLS handshake immediately when the connection opens, with no plaintext phase at all (used on 443, 465, 993, 995, 636, and 990). Explicit TLS, commonly called STARTTLS, starts as a plaintext session and only upgrades to TLS after the client sends a command the server acknowledges (used on 587, and on 389 or 21 when upgraded), which leaves a brief plaintext window that attackers have historically targeted with STARTTLS stripping and command-injection attacks.

Does changing a service to a nonstandard port improve its security? Not meaningfully. Port scanners routinely fingerprint services regardless of which port they listen on, so moving a service off its standard port mainly adds friction for legitimate clients rather than blocking a determined scan. The effective controls are restricting which ports are open at all, enforcing mandatory TLS on any explicit/STARTTLS port, and keeping certificates current on every port that is open.

Conclusion

A TLS/SSL port is where a protocol’s encrypted traffic lands, either through implicit TLS that encrypts from the first byte (443, 465, 993, 995, 636, 990) or through an explicit STARTTLS upgrade on a port that starts in plaintext (587, and 389 or 21 when upgraded). Choosing the right port and mode for each protocol, hardening firewall rules around it, and testing the actual negotiated handshake rather than trusting the port number all matter, but none of it holds up without the certificate and key-management program behind it. A valid certificate, a complete chain, and a renewal process that reaches every TLS-terminating port are what keep the handshake succeeding on all of them, not just the ones an IT team happens to check first.

References

• Service Name and Transport Protocol Port Number Registry, IANA
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, IETF
• RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security, IETF
• RFC 8314: Cleartext Considered Obsolete, Use of Transport Layer Security (TLS) for Email Submission and Access, IETF
• RFC 4217: Securing FTP with TLS, IETF
• Why TLS Is Better Without STARTTLS: A Security Analysis of STARTTLS in the Email Context, Poddebniak et al., USENIX Security 2021
• What Is SNI? How TLS Server Name Indication Works, Cloudflare Learning Center