Port 8443 – HTTPS (Alternative HTTPS Port for Admin Consoles & SSL-VPN)

Port 8443 is the internet’s default alternative HTTPS port — the TLS sibling of plaintext port 8080. It speaks the same HTTP-over-TLS that port 443 does, but on a non-privileged port a process can bind without root. That combination is why 8443 is the reflexive choice for product admin consoles and appliance management interfaces: Apache Tomcat’s SSL connector defaults to 8443, and Plesk, VMware Workspace ONE, SonicWall and Ivanti appliances, Spring Boot HTTPS apps, minikube’s Kubernetes API, and Elasticsearch/Kibana behind TLS all serve their web UIs here. For a pentester an open 8443 is a two-part target: the TLS transport (certificate, protocols, ciphers) and the web application or admin console behind it — because encrypted transport does nothing to make the app itself safe. The heaviest 8443 findings are unauthenticated RCEs in the admin and SSL-VPN portals that vendors assumed no one would ever expose to the internet.

Why It’s Open

Port 8443 is open because something wanted HTTPS without needing port 443 or root privileges. The usual occupants:

• Apache Tomcat SSL connector. Tomcat’s sample server.xml ships an HTTPS connector on 8443 (with 8080 for plaintext and 8005/8009 for shutdown/AJP). A default Tomcat left running is one of the most common things you’ll ever find on 8443.
• Product and appliance admin consoles. Plesk serves its control panel on 8443, VMware Workspace ONE Access / Identity Manager exposes its /cfg admin app on 8443, SonicWall SMA appliances run their Appliance Management Console (AMC) on 8443, and Ivanti/MobileIron Sentry puts its MICS System Manager portal on 8443. Vendors pick 8443 precisely because it’s the “secure admin” convention.
• SSL-VPN and remote-access portals. Many SSL-VPN and gateway products publish a user or admin portal over HTTPS on 8443 (or an adjacent high port) instead of, or alongside, 443.
• Application frameworks and dev stacks. Spring Boot apps with TLS enabled, minikube’s Kubernetes API server, Elasticsearch/Kibana fronted by TLS, and countless internal tools bind 8443 so they can run HTTPS as a non-root service.

Because so many different products default here, the first job on an open 8443 — as on port 8000 — is to fingerprint what is answering, then assess that specific product.

Common Risks

The TLS wrapper on 8443 protects data in transit; it does not protect the console behind it. Most 8443 findings come from the application, not the crypto:

• Exposed admin consoles that were meant to be internal. SonicWall AMC, Ivanti MICS, Plesk, and VMware /cfg are administrative interfaces vendors explicitly tell you to keep off the public internet. An internet-facing 8443 admin portal is often the whole finding.
• Unauthenticated RCE in appliances. SSL-VPN and management portals on 8443 have a long track record of pre-auth remote-code-execution bugs (see CVEs below). A single request to an unpatched console can mean full box takeover.
• Default Tomcat Manager / weak credentials. A Tomcat SSL connector on 8443 with the Manager app reachable and default or weak creds lets an attacker deploy a malicious WAR and get code execution.
• Self-signed, expired, or default-vendor certificates. Appliance consoles ship self-signed certs that admins rarely replace, breaking TLS authentication and making on-path interception realistic rather than theoretical.
• Weak TLS configuration. Old appliances still negotiate TLS 1.0/1.1, RC4, or 3DES. Those transport-layer attacks are real, but they’re the same cluster covered in depth on port 443 — on 8443 they’re usually a symptom of an unpatched box, and the app behind the cert is the bigger prize.
• Encryption hides the payload. TLS terminates at 8443, so SQLi, SSRF, path traversal, and deserialization all ride inside the tunnel where a network IDS watching cleartext is blind.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Testing 8443 is a two-step: audit the TLS transport, then fingerprint and attack the web app behind it.

Confirm the service, grab the certificate, and grade the crypto

nmap -sV -p 8443 --script ssl-cert,ssl-enum-ciphers <target>

ssl-cert prints the certificate (issuer, hostname, expiry — self-signed vendor certs stand out immediately) and ssl-enum-ciphers grades every protocol and ciphersuite A–F, so a single scan flags TLS 1.0, RC4, or 3DES.

Dig deeper into the TLS layer

sslscan <target>:8443
testssl.sh https://<target>:8443
openssl s_client -connect <target>:8443 -servername <target>

Fingerprint the web app / admin console behind the TLS

curl -kvI https://<target>:8443/
whatweb https://<target>:8443
nmap -p 8443 --script http-title,http-headers,http-methods <target>

The -k flag tells curl to ignore the self-signed cert so you can read the real response. A Server: header, redirect target, favicon, or login-page branding usually names the product (Tomcat, Plesk, SonicWall, VMware, Ivanti) — write down the exact version, because that’s what maps to the CVEs.

Check for an exposed Tomcat Manager

curl -k https://<target>:8443/manager/html
curl -k https://<target>:8443/host-manager/html

A reachable Manager app is a WAR-deploy RCE waiting on weak or default credentials.

Scan the application

nikto -h https://<target>:8443
# then drive auth, session, and injection testing through Burp Suite or OWASP ZAP

Log every weak protocol, self-signed cert, exposed console, and product/version you confirm so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Vulnerabilities on 8443 split into two families: the TLS transport (protocol, cipher, and library bugs like Heartbleed, POODLE, and DROWN) and the application or appliance behind it. The TLS-transport cluster is identical to the one on standard HTTPS and is documented in full on the port 443 page — there’s no point duplicating it here. What makes 8443 distinct is the concentration of admin-console and SSL-VPN portals, and that’s where its signature CVEs live. Every entry below is NVD-verified and genuinely served on 8443:

• CVE-2023-38035 — Ivanti / MobileIron Sentry (MICS Admin Portal, 8443). An insufficiently restrictive Apache HTTPD configuration lets an unauthenticated attacker bypass authentication on the System Manager (MICS) admin portal, which listens on TCP 8443 by default, then change system configuration, run OS commands, and write files to disk. CVSS 9.8 (CWE-863). Exploited as a zero-day and listed in CISA’s Known Exploited Vulnerabilities catalog; Ivanti’s interim guidance was literally “make sure 8443 isn’t internet-accessible.”
• CVE-2025-23006 — SonicWall SMA1000 Appliance Management Console (8443). A pre-authentication deserialization-of-untrusted-data flaw in the SMA1000 Appliance Management Console (AMC) and Central Management Console (CMC) — reached at https://<appliance>:8443 — can let a remote, unauthenticated attacker execute arbitrary OS commands. CVSS 9.8 (CWE-502). Exploited in the wild and added to CISA KEV.
• CVE-2021-22002 — VMware Workspace ONE Access / Identity Manager (/cfg on 8443). The /cfg administrative web app and diagnostic endpoints normally restricted to port 8443 could be reached via port 443, allowing an attacker to abuse the host header and access administrative functionality without proper authentication. CVSS 9.8 (CWE-287). A clean illustration of why the 8443 admin surface must be firewalled, not just “on a different port.”

Honest notes on scope:

• The previous version of this page listed CVE-2021-38507 as an “8443 vulnerability.” It is not — it’s a Firefox/Thunderbird HTTP/2 opportunistic-encryption origin-validation bug in the browser, where 8443 appears only as an example port in the write-up. No service on 8443 is affected, so it has been removed.
• FortiOS “XORtigate” (CVE-2023-27997), Pulse Connect Secure, and Cisco ASA SSL-VPN RCEs are real and matter, but those appliances default their SSL-VPN portals to 443 (or 10443), not 8443 — they’re covered on the port 443 page rather than duplicated here.
• Tomcat, Plesk, Spring Boot, and Kibana all commonly sit on 8443, but their CVEs (Tomcat’s Ghostcat is AJP on 8009, not 8443; deserialization and manager-app bugs, etc.) are product-specific, not port-specific. Fingerprint the exact product and version on 8443 and check that product’s advisories — there is no generic “port 8443 CVE.”

Mitigation

• Keep admin consoles off the public internet. SonicWall AMC, Ivanti MICS, Plesk, and VMware /cfg on 8443 should be reachable only from a management VLAN or over VPN. Firewall 8443 to trusted source IPs — most of the marquee CVEs above stop mattering the moment the console isn’t internet-facing.
• Patch the product behind the cert, fast. The 9.8s on 8443 are appliance and admin-console bugs. Treat any SSL-VPN or management portal here as a top-priority patch target and subscribe to the vendor’s advisories.
• Harden Tomcat. Remove or lock down the Manager/Host-Manager apps, set strong unique tomcat-users.xml credentials, and don’t run the default sample config on an internet-facing 8443.
• Fix the TLS config too. Serve TLS 1.2/1.3 only, drop RC4/DES/3DES, and replace self-signed vendor certs with trusted-CA certificates — aim for an A in sslscan/testssl.sh. (The full TLS-hardening checklist is on the port 443 page.)
• Enforce authentication and MFA on every admin interface, and don’t rely on “it’s on 8443” as a security control.
• Don’t trust the tunnel to hide the app. TLS encrypts transit; it doesn’t stop SQLi, SSRF, or deserialization. Test the application on 8443 the same way you’d test anything on 80 or 8080, and capture what you find in your pentest report.

Real-World Example

In August 2023, Ivanti Sentry’s admin portal on port 8443 became the textbook 8443 incident. CVE-2023-38035 — an authentication bypass in the MICS System Manager portal caused by a too-permissive Apache HTTPD config — was exploited as a zero-day before a patch existed. Because the portal listened on 8443 over HTTPS, plenty of operators assumed the encrypted, “non-standard” admin port was low-risk and left it reachable. It wasn’t: an unauthenticated attacker who could reach 8443 could bypass the login entirely and then change configuration, run system commands, and write files to disk — full compromise of a device that fronts a fleet of managed mobile endpoints. Ivanti’s own emergency guidance told administrators to make sure port 8443 was not internet-accessible while they patched, and CISA added the bug to its Known Exploited Vulnerabilities catalog. It’s the port-8443 lesson in one CVE: the TLS was fine, the port number felt obscure, and the application behind the cert handed attackers the keys.

FAQ

What is port 8443 used for?

Port 8443 is the standard alternative HTTPS port — HTTP wrapped in TLS, served on a non-privileged port a process can bind without root. It’s the default for Apache Tomcat’s SSL connector and for a long list of product admin consoles and SSL-VPN portals: Plesk, VMware Workspace ONE, SonicWall SMA, Ivanti Sentry, Spring Boot HTTPS apps, minikube’s Kubernetes API, and Kibana behind TLS all commonly answer on 8443.

What is the difference between port 443 and port 8443?

Both carry HTTPS (HTTP over TLS). Port 443 is the standard HTTPS port that browsers use by default and that owns the classic TLS-transport attacks (Heartbleed, POODLE, DROWN). Port 8443 is an alternative HTTPS port on a high, non-privileged number, used mostly for product admin consoles, appliance management, and SSL-VPN portals rather than public websites. Same protocol, different role — and 8443’s biggest risks are the admin apps behind it.

Is port 8443 secure?

The encryption is only half the story. Traffic to 8443 is encrypted, but “HTTPS” doesn’t make the console behind it safe — the port has a heavy history of unauthenticated RCE in admin and SSL-VPN portals (Ivanti Sentry, SonicWall SMA, VMware Workspace ONE). An internet-facing 8443 admin console with an old build is a serious exposure regardless of how good its TLS config is.

Why is port 8443 open on my server?

Almost always because something wanted HTTPS without port 443 or root. The usual culprits are Apache Tomcat’s default SSL connector, a Plesk control panel, a VMware/SonicWall/Ivanti appliance console, a Spring Boot app with TLS enabled, or a Kubernetes/Kibana stack behind TLS. Fingerprint it (curl -kvI https://<host>:8443/ and whatweb) to see exactly which product is listening.

How do I test port 8443 for vulnerabilities?

Audit the transport first — nmap -sV -p 8443 --script ssl-cert,ssl-enum-ciphers <host>, sslscan, or testssl.sh to grade the certificate and ciphers. Then fingerprint the app (curl -kvI, whatweb, http-title) to identify the exact product and version, check that product’s CVEs, look for an exposed Tomcat Manager, and test the web app itself with Nikto, Burp Suite, or OWASP ZAP.

Is port 8443 TCP or UDP?

TCP. HTTPS over TLS on 8443 is a TCP service, so scan it with nmap -sV -p 8443 (a TCP connect/SYN scan), not a UDP scan.

TL;DR

• Service: alternative HTTPS (HTTP over TLS) — Apache Tomcat’s SSL connector plus admin/SSL-VPN consoles for Plesk, VMware Workspace ONE, SonicWall SMA, Ivanti Sentry, Spring Boot, and Kibana
• Default port: 8443/TCP (the TLS sibling of plaintext 8080; the standard HTTPS port is 443)
• Biggest risk: unauthenticated RCE and auth-bypass in internet-facing admin/SSL-VPN consoles (CVE-2023-38035 Ivanti Sentry, CVE-2025-23006 SonicWall SMA1000, CVE-2021-22002 VMware Workspace ONE) — encrypted transport doesn’t make the app safe
• Mitigation: keep admin consoles off the public internet and firewall 8443 to trusted IPs, patch the appliance behind the cert, harden Tomcat and replace self-signed certs, serve TLS 1.2/1.3 only, and test the web app inside the tunnel