Port 4443 – HTTPS Alternate

TCP

Port 4443 is a common alternate HTTPS port used when port 443 is occupied by another service. Kubernetes API servers, development environments, and application proxies frequently use port 4443. Pharos, Kubernetes CNI plugins, and some ingress controllers default to port 4443 for internal HTTPS traffic.

Port Number

4443

Protocol

TCP

Service

HTTPS (non-standard)

Range

IANA Registered (1024–49151)

Description

Port 4443 serves as a secondary HTTPS endpoint when port 443 is already in use. Common scenarios include: running multiple HTTPS services on the same host, development servers alongside production, and Kubernetes components that need their own TLS endpoints separate from the main ingress. Kubernetes uses port 4443 for several internal purposes – the metrics-server API, some CNI plugin webhooks, and custom admission controllers. When troubleshooting Kubernetes certificate errors on port 4443, check that the serving certificate's SAN list includes the service DNS name. Port 4443 carries TLS traffic identical to port 443 – clients must specify the port explicitly since browsers do not default to it.

Security risks

1Shadow services: port 4443 often hosts internal services (Kubernetes admission webhooks, internal APIs) that bypass the main ingress security controls (WAF, rate limiting, authentication) applied on port 443
2Kubernetes admission controller target: many admission webhooks (OPA Gatekeeper, Kyverno, cert-manager) listen on 4443 – compromising these allows injecting policies that affect all cluster workloads
3Certificate management oversight: services on non-standard ports often have self-signed or expired certificates because they're excluded from automated cert renewal (Let's Encrypt only works on 80/443)
4Developer backdoors: port 4443 is commonly used for local development HTTPS servers that accidentally remain running in production (Next.js dev, Vite, webpack-dev-server)
5Rancher dashboard: Rancher Kubernetes management uses port 4443 – exposed Rancher instances give full cluster management access

Firewall guidance

Audit what runs on 4443 – it's often an internal service that shouldn't be exposed beyond the cluster. In Kubernetes: admission webhooks on 4443 should only be reachable from the API server (use NetworkPolicy). For Rancher: restrict to admin IPs only (same as any management plane). Never expose 4443 to the internet without knowing exactly what's behind it.

Diagnosis commands

Check what's serving on 4443 locally

shell

curl -sk https://localhost:4443/ | head -5

Identify the process bound to port 4443

shell

ss -tlnp | grep 4443

Find Kubernetes webhooks using port 4443

shell

kubectl get mutatingwebhookconfigurations -o jsonpath='{range .items[*]}{.metadata.name}: {.webhooks[*].clientConfig.service.port}{"
"}{end}'

Identify service and certificate on 4443

shell

nmap -sV -p 4443 --script ssl-cert target

Usage examples

Port 4443 – HTTPS Alternate

shell

curl https://host:4443/healthz
openssl s_client -connect host:4443 -servername service.namespace.svc
kubectl get --raw /apis --server=https://host:4443

Common services on this port

Kubernetes admission webhooksRancher dashboardPharos/KontenaDevelopment HTTPS serversDocker Registry (alternate TLS)

Related ports

443

HTTPS (standard)

4443

HTTPS alternate (this port)

8443

HTTPS alternate (another common choice)

6443

Kubernetes API server

History

Port 4443 emerged organically as a secondary HTTPS port when 443 is already occupied by the main web server or load balancer. Kubernetes ecosystem adopted it heavily: many admission controllers and internal services default to 4443 to avoid conflicting with the API server (6443) and ingress (443). Rancher chose 4443 for its management UI. There is no IANA registration for 4443 – it's a de facto convention.

FAQ

Why do Kubernetes webhooks use 4443 instead of 443?

Convention and conflict avoidance. Admission webhooks run as Services inside the cluster. Port 443 would conflict with the ingress controller or other services. Port 4443 became the community default (cert-manager, OPA Gatekeeper, Kyverno all use it). The webhook configuration tells the API server which port to call. Security note: the API server authenticates to webhooks via the webhook's CA bundle, not just the port.