What Is Port 443 and How Is It Used for HTTPS and Network Security?

Port 443 is the dedicated port for HTTPS interactions, and as such, facilitates a basic component of everyday web browsing. You can think of port 443 as a conduit facilitating secure interactions between clients and browsers, such as the TLS handshake that enables encryption.

This guide covers what port 443 is, how the TLS handshake works, what makes a certificate valid, what happens when it is not, and how the same certificate infrastructure that secures HTTPS extends into enterprise network authentication.

What Is Port 443?

Port 443 is the default TCP port for HTTPS — the encrypted version of HTTP. Sometimes called the Secure Sockets Layer (SSL) port, it is more accurately described as the Transport Layer Security (TLS) port as connections on port 443 are secured using TLS, and the server is authenticated with a digital certificate issued by a Certificate Authority (CA).

In networking, a port is a starting and ending point for communication over a network, with each port typically tied to a unique function or service. Ports allow a single server to run multiple services simultaneously: port 443 handles HTTPS, port 25 handles SMTP, port 22 handles SSH, and so on. The port number tells the receiving system which application should handle the incoming traffic. Applications that require an alternative to port 443 sometimes use port 8443.

Port 443 specifically signals that a connection expects HTTPS, which means encryption via TLS and certificate-based server authentication. Without a valid certificate, the connection either fails or triggers a browser warning. The port itself offers no encryption — that comes from the TLS handshake, which happens immediately after the TCP connection is established.

Port 80 vs. Port 443: What’s the Difference?

Port 80 is the default port for HTTP, the unencrypted predecessor to HTTPS. Requests on port 80 are transmitted as plaintext, so anyone with access to the network path can read the content, modify it in transit, or inject malicious code.

Port 443 adds encryption and server authentication, and today, most web servers are configured to redirect any port 80 request to port 443.

Port 80 is still assigned by IANA and active on many servers, but its role is almost exclusively to redirect traffic to port 443.

How Port 443 Works: The TLS Handshake

When a client connects to a server on port 443, a multi-step process called the TLS handshake occurs before any application data is exchanged. The handshake authenticates the server and establishes the encryption parameters, like session keys, for the session.

The TLS 1.3 handshake — the current standard, defined in RFC 8446 — completes in one round trip. Here is the sequence:

1. ClientHello: The client sends a message with the TLS version it supports, a list of cipher suites (encryption algorithms), and a randomly generated value used later in key derivation.
2. ServerHello: The server responds by selecting a TLS version and cipher suite from the client’s list, and sends its own random value.
3. Certificate presentation: The server sends its TLS certificate — a digitally signed document containing the server’s public key and identity information (domain name, issuing CA, validity dates).
4. Certificate validation: The client checks the certificate against its trust store. Is the certificate issued by a CA the client trusts? Is it within its validity period? Has it been revoked (checked via OCSP or a CRL)? Does the domain name match?
5. Key exchange: Both parties use the exchanged values and the server’s public key to derive a shared session key. TLS 1.3 uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key exchange in the most common configuration, which provides forward secrecy.
6. Finished messages: Both parties send a Finished message encrypted with the session key, confirming the handshake was not tampered with.
7. Encrypted application data: With the handshake complete, all subsequent traffic on port 443 is encrypted symmetrically using the session key.

What Makes Port 443 Secure: TLS Certificates and Certificate Authorities

Port 443 connections are only as trustworthy as the certificates that authenticate them. Understanding what a TLS certificate does — and what can go wrong — is the foundation of a certificate-based security practice.

What Is a TLS Certificate?

A TLS certificate is a digitally signed file that binds a public key to an identity. For a web server, that identity is typically a domain name. The certificate contains:

• The subject (domain name or organization)
• The subject’s public key
• The certificate’s validity period (not before/not after dates)
• The issuing Certificate Authority (CA)
• The CA’s digital signature pertaining to all of the above

When a browser receives a certificate, it uses the CA’s public key — already embedded in the browser’s trust store — to verify the signature. If the signature is valid and the CA is trusted, the browser accepts the certificate.

The CA Trust Chain

Certificates are issued through a hierarchy:

• Root CA: A self-signed certificate at the top of the trust hierarchy. Root CA certificates are embedded directly in operating systems and browsers. Their private keys are kept offline and used only to sign intermediate CA certificates.
• Intermediate CA: An intermediate certificate authority sits between the root and the end-entity certificate. Intermediate CAs are the entities that actually issue certificates to servers and devices. Using intermediates limits the exposure of the root CA’s private key.
• End-entity (leaf) certificate: The certificate installed on the server or device. It links through one or more intermediates to a trusted root.

When a browser validates a certificate through port 443, it walks this chain from the end-entity certificate up to a trusted root. If any link in the chain is missing, expired, or signed by an untrusted CA, validation fails.

What Happens When Certificate Validation Fails

Certificate validation failures are the most common cause of port 443 errors in production environments:

• Expired certificate: The server’s certificate has passed its not-after date. Browsers refuse the connection with an “ERR_CERT_DATE_INVALID” or similar error. If an attacker obtains an expired certificate they may use it against clients that do not enforce strict validation.
• Self-signed certificate: The certificate was not issued by a trusted CA — it was signed by the same entity that generated it. Browsers do not trust self-signed certificates by default and warn users before proceeding.
• Revoked certificate: The CA has revoked the certificate before its expiration date, typically because the private key was compromised. Revocation status is distributed via OCSP (Online Certificate Status Protocol) or a CRL (Certificate Revocation List). Both run over port 80 and port 443, which means blocking those ports at a firewall can break certificate validation across an environment.
• Domain mismatch: The domain in the certificate’s subject does not match the domain the client is connecting to. This indicates either a misconfiguration or a potential MITM attack.
• Incomplete chain: The server does not serve the full certificate chain, including intermediates. The client cannot build a path to the trusted root.

Certificate lifecycle management — monitoring expiration, automating renewal, and maintaining correct chain configuration — is a continuous operational requirement for any organization running services on port 443.

Common Threats Targeting Port 443

Running services on HTTPS through port 443 does not automatically confer security, as other layers of the security architecture have vulnerabilities. The following threats target TLS connections specifically:

Man-in-the-middle (MITM) attacks intercept traffic between the client and server. On port 443, a successful MITM requires the attacker to present a certificate that the client trusts — either a certificate issued by a compromised CA, a forged certificate if the client does not enforce strict validation, or a certificate installed by an attacker with control over the client device. TLS 1.3 and strict certificate validation significantly limit MITM risk.

SSL stripping downgrades a connection from HTTPS (port 443) to HTTP (port 80) before the client can react. A client that requests http://example.com and is then silently redirected to an HTTP version by a network attacker never establishes a port 443 connection at all. HTTP Strict Transport Security (HSTS) mitigates this by instructing browsers to always use HTTPS for a given domain — even if the URL is typed without https://.

Expired and/or misconfigured certificates are an operational vulnerability. An expired certificate on a public-facing service is visible to every attacker scanning port 443 with certificate inspection tools. A self-signed certificate accepted by an internal application represents a trust gap that an attacker can exploit by presenting their own self-signed certificate.

Weak cipher suites— particularly those supporting TLS 1.0, TLS 1.1, RC4, or export-grade encryption — allow attacks such as BEAST (TLS 1.0), POODLE (SSL 3.0), and LOGJAM (weak DH primes). Disabling legacy TLS versions and enforcing strong cipher suites (AES-GCM, ChaCha20-Poly1305) addresses these.

DDoS against port 443 targets the TLS handshake itself. A TLS handshake is computationally more expensive than a TCP SYN — an attacker sending large volumes of TLS ClientHello messages can exhaust server resources. Rate limiting, TLS session resumption, and web application firewalls are standard mitigations.

Port 443 Beyond the Browser: Enterprise Network Security

Port 443 is typically discussed as a component of HTTPS, connecting browsers to websites. But this TLS certificate-based security model is a part of a modern enterprise-level approach to network security. Adding features like mutual TLS (mTLS) ensures both client and server are properly authenticated, a key upgrade for enterprises where, unlike a public website, client identity needs to be verified.

When to Use Mutual TLS

Standard TLS authenticates the server to the client. The client checks the server’s certificate, but the server does not verify the client’s identity beyond the TCP connection. This is sufficient for a public website but insufficient for enterprise applications, where verifying the identity and security status of a client is necessary.

mTLS extends the TLS handshake so that both parties present and validate a certificate. The server presents its certificate, as usual. The client also presents a certificate issued by a CA that the server trusts. If the client certificate is valid, trusted, and not revoked, the server accepts the connection. If not, the connection is rejected before any application data is exchanged.

The use of mTLS is how:

• Enterprise services authenticate each other in continuous trust architectures
• APIs enforce client identity in machine-to-machine communication
• Certificate-based authentication extends beyond the browser to devices and services

HTTPS connections using mTLS also use port 443. The difference is that both sides of the connection participate in certificate validation.

802.1X and EAP-TLS: The Same Trust Model for Wi-Fi

802.1X is the IEEE standard for port-based network access control. It governs how devices authenticate to a network before they are granted access to network resources, on wired and wireless connections alike.

The strongest authentication method within 802.1X is EAP-TLS (Extensible Authentication Protocol — Transport Layer Security). Under this standard, EAP-TLS performs a TLS handshake between the device (the supplicant) and a RADIUS authentication server, with both sides presenting certificates. The device presents a certificate that the RADIUS server validates against a trusted CA. If the certificate is valid, the device is granted network access. If not, the connection is blocked at the switch or access point.

This is the same trust mechanism and certificate infrastructure as mTLS: end-entity certificates issued by an intermediate CA that chains to a trusted root. The only difference is that instead of a browser checking a web server’s certificate, a RADIUS server is checking a device certificate.

RADIUS Certificate Authentication

RADIUS servers that handle 802.1X authentication must themselves present a certificate to the supplicant — a server certificate, validated by the device during the EAP-TLS handshake. This prevents rogue access points from intercepting authentication traffic by impersonating the RADIUS server.

Cloud RADIUS deployments — where the RADIUS server is hosted in a cloud environment rather than on-premise — communicate over HTTPS and TLS for management operations, identity provider lookups (checking user status against Entra ID, Okta, or Google Workspace in real time), and certificate validation. The communication patterns are identical to port 443: TLS-encrypted, certificate-authenticated.

RadSec (RADIUS over TLS, RFC 6614) takes this further, running RADIUS authentication traffic itself over TLS — typically on port 2083. The certificate validation model is the same as port 443: both the RADIUS client and server present certificates, and both parties validate them before exchanging authentication messages.

RadSec is particularly relevant for cross-institutional environments like Eduroam, where RADIUS traffic must traverse the public internet securely.

OCSP and CRL Traffic Over Port 443

Certificate revocation checks are a common source of confusion in enterprise firewall rules. When a browser or device validates a certificate on port 443, it contacts the OCSP responder or downloads a CRL to check whether the certificate has been revoked. That OCSP request goes out over port 80 or port 443 to a URL specified in the certificate’s Authority Information Access (AIA) extension.

If an enterprise firewall blocks outbound requests to OCSP responder URLs or CRL distribution points, certificate validation may fail or silently degrade (many implementations treat a failed OCSP check as “soft fail” — the certificate is accepted anyway, which defeats the purpose of revocation). Organizations that run cloud-hosted PKI need outbound port 443 access to their CA’s OCSP and CRL endpoints, or they risk silent failures in certificate validation across their environment.

Certificate-Based Authentication and Port 443: Why Certificates Matter More Than the Port

Port 443 is typically thought of in the context of HTTPS TLS. That’s accurate, but there’s a better way to think about this for IT teams managing infrastructure at scale:

Port 443 works because certificates work. Certificates work because PKI works.

PKI — Public Key Infrastructure — is the system of CAs, certificate policies, issuance workflows, and revocation mechanisms that makes certificate-based trust possible. TLS certificates on a web server, device certificates for EAP-TLS authentication and client certificates for mTLS are all PKI artifacts.

The operational challenge for enterprise IT is not configuring a single certificate on a web server. It is managing certificates at scale:

• Issuing device certificates to hundreds or thousands of managed devices via MDM integrations (Intune, Jamf, Google Workspace, Kandji)
• Issuing certificates to BYOD devices through a self-service enrollment workflow
• Monitoring certificate expiration across all endpoints — web servers, network devices, client certificates
• Automating certificate renewal before expiration causes service disruption
• Revoking certificates immediately when a device is decommissioned or a user is offboarded

These operational challenges make PKI management complex at enterprise scale, and the same ones that make certificate-based network authentication, not just HTTPS, the real challenge for security teams.

How to Check Whether Port 443 Is Open

For network administrators confirming that port 443 is accessible on a host, the following commands are standard:

Using curl (cross-platform):

curl -I https://hostname

A response of HTTP/2 200 or a redirect confirms port 443 is open and a certificate is being served.

Using telnet:

telnet hostname 443

A successful TCP connection without an immediate error confirms the port is reachable. You will see a blank prompt — type anything to trigger a response.

Using nmap:

nmap -p 443 hostname

Returns 443/tcp open https if the port is open.

Using PowerShell (Windows):

Test-NetConnection hostname -Port 443

Returns TcpTestSucceeded : True if the connection succeeds.

Using openssl (confirms TLS, not just port):

openssl s_client -connect hostname:443

Returns the full TLS handshake and certificate chain — useful for diagnosing certificate errors.

Port 443 Security Best Practices

For organizations running services on port 443 — web servers, APIs, management interfaces, or cloud PKI endpoints:

• Enforce TLS 1.2 at a minimum; prefer TLS 1.3: Disable TLS 1.0 and 1.1, which have known vulnerabilities (BEAST, POODLE). TLS 1.3 removes weak cipher suites entirely and reduces handshake latency.
• Use strong cipher suites: Prefer ECDHE key exchange (for forward secrecy), AES-GCM or ChaCha20-Poly1305 for encryption, and SHA-256 or higher for hashing. Disable RC4, 3DES, and export ciphers.
• Implement HSTS: HTTP Strict Transport Security instructs browsers to always connect on port 443 for a given domain, preventing SSL stripping attacks. Set the max-age to at least 31536000 (one year) and include subdomains.
• Enable OCSP stapling: Rather than requiring the client to contact the OCSP responder directly, the server periodically fetches the OCSP response and staples it to the TLS handshake. This speeds up validation and reduces privacy exposure.
• Monitor certificate expiration: Automated monitoring for certificate expiration is not optional at enterprise scale. An expired certificate on a production service is an availability incident and a potential security gap.
• Automate certificate renewal: The ACME protocol (used by Let’s Encrypt and supported by enterprise CA platforms) automates issuance and renewal. For internal certificates, SCEP and EST protocols provide automation pathways integrated with MDM platforms.
• Audit internal services for self-signed certificates: Self-signed certificates accepted by internal applications represent trust gaps. Auditing internal services and replacing self-signed certificates with certificates from an internal CA removes those gaps without requiring a public CA.
• Verify OCSP and CRL URLs are reachable: Confirm that firewall rules allow outbound access to the OCSP responder and CRL distribution point URLs specified in your certificates. Blocking these silently degrades certificate validation.

Managing Certificates Beyond Websites

Port 443 is just a routing mechanism for things like TLS handshakes. Security comes from the certificate.

For organizations running web servers, that means obtaining certificates from a public CA, monitoring expiration, and enforcing TLS 1.2 or 1.3 are nonnegotiable.

For organizations that have extended certificate-based trust to their network — issuing device certificates for EAP-TLS and 802.1X authentication, using certificate-based RADIUS authentication, or managing a full PKI infrastructure that covers devices, users, and services — the operational complexity is substantially higher. Certificate issuance at scale, automated enrollment via MDM, revocation tied to identity provider status, and certificate lifecycle monitoring across thousands of endpoints are problems that require a purpose-built platform, not a manual CA workflow.

SecureW2 provides a cloud-native Managed PKI platform and JoinNow Cloud RADIUS that handle the full certificate lifecycle — from automated device onboarding to real-time certificate validation against live identity provider data. Organizations managing certificate-based authentication for Wi-Fi, VPN, and network access can deploy across existing MDM and identity provider environments without adding on-premise infrastructure.

Schedule a demo to see how SecureW2 handles certificate issuance, enrollment, and lifecycle management at enterprise scale — or contact us to discuss your specific environment.