SSTP Took Port 443: Why Apache Will Not Start

Apache stops answering on 443 the afternoon someone enables incoming VPN connections, and its error log blames the bind instead of the reservation behind it. Windows Routing and Remote Access turns on SSTP at that moment, and the SSTP listener claims TCP 443 through the HTTP stack before any client authenticates. The claim holds even when the certificate is missing, the name is wrong, or every handshake is rejected, so a VPN that nobody can log in to still parks on the port. Read the listen table first; the PID that owns 443 decides which of the fixes below is even open to you.

The Reservation Outlives a Broken Certificate

SSTP wraps PPP inside a TLS session, which is why it needs 443 and why it travels through proxies that drop other tunnels. The listener is not a socket the VPN service opens for itself: SstpSvc registers it with the kernel HTTP driver, so the port stays reserved for as long as the service runs. That registration never consults the certificate, which means an expired name, a mismatched subject, or no certificate at all leaves 443 occupied. Failures then split in two directions: rejected handshakes land in the System log under RasSstp, while the web server can only report that it could not bind.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

The first line returns the owning PID; the second names the service behind it, and the answer is usually the HTTP service or the RRAS stack. When tasklist answers with a shared host process, read the service column rather than guessing from the process name.

RasSstp warnings are worth reading only after that, because they describe a handshake that failed and say nothing about the reservation that caused the collision. A VPN endpoint rejecting every client still owns the port. Treat the log as the second question, not the first.

IIS Shares the Driver, Apache Opens a Socket

IIS hands its bindings to the same kernel driver that SSTP uses, and that driver demultiplexes incoming connections by host name and URL prefix, so both services can be told to want 443 without either of them failing. Apache and nginx do the opposite: they call bind on their own socket, and the operating system refuses because the address is already held. Nothing in either configuration is wrong; the difference sits in which API owns the port. That is also why enabling the VPN takes down one site on a host and leaves an identical site on another host untouched.

This asymmetry decides the shape of the repair. If IIS is already the front door, the collision becomes a question about prefixes, bindings and certificates. If Apache is the front door, either it moves off 443 or the SSTP listener does, and the next section covers both moves.

Pick Which Service Keeps 443

The listener port lives in a single registry value, a decimal DWORD under the Sstpsvc parameters key. Change the value, restart Routing and Remote Access, and confirm from the listen table that the old port is free.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

Choose a port nothing else on the host wants, and type it in decimal: reg add stores the DWORD exactly as written, so a value intended as hexadecimal lands as a different port. If the query says the value does not exist, the second line creates it. Restart-Service RemoteAccess drops everyone who is connected, which is worth scheduling. Re-run the listen check afterwards, because a stale entry on 443 means the service kept its old registration.

Moving the listener carries a price the registry edit does not show. Ordinary SSTP clients dial 443, so every client profile needs the new port, and the flow stops resembling a web request to anything inspecting the path. On a network that only tolerates traffic which looks like HTTPS, that removes most of the reason SSTP was chosen. A small, managed client population absorbs this; a public or BYOD user base does not.

The other move keeps 443 with IIS and treats Apache as a backend the proxy forwards to. It preserves the SSTP default and leaves one owner for the port, at the cost of forwarded headers, a client address the application no longer sees directly, and a backend that must speak the protocol the proxy actually sends.

Prove the Owner, the Certificate and the Handshake in Order

A completed TCP connection proves that a listener exists and nothing else, which is why a port scan can look healthy while the tunnel still fails. The four stages fail in different ways, and a repair aimed at the stage you did not break usually deepens the collision. Work them in order and stop where the answer diverges.

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

The first line names the PID holding 443, and it should be the service you just configured. The second lists machine certificates with their subjects, so a name that does not match the address in the client profile stands out at once. The event query returns recent SSTP records, and a handshake that never reaches PPP authentication leaves a different record from one that authenticates and is then refused. The last stage is visible only on the client, where the entry either reports connected or names the PPP error.

When one host must do both jobs, choose the owner of 443 deliberately and write the choice down, because the next person to enable a feature will otherwise rediscover this collision. Splitting the roles stays the cleaner answer: a public web server and a remote-access endpoint carry separate patch, certificate and restart cycles, and those cycles meet on their own schedule. Either way, leave the listen check, the registry path and the chosen port in the handover note.