Aposto que é o Skype. Desmarque a caixa de verificação mostrada abaixo se o tiver instalado.

Execute o seguinte a partir de um prompt de comando elevado:

netstat -ab

Em primeiro lugar, vou responder directamente a esta pergunta e qualquer pessoa que a ler pode ignorar quaisquer respostas que falem de aplicações de terceiros, não-Microsoft, utilizando o Processo de Sistema.

1. o processo Sistema está listado como PID 4 em todos os sistemas Windows dos dias modernos. É para acesso ao kernel-mode. Isto exclui a maioria dos produtos Web de terceiros, como o Apache.

2. Desde o início do WinRM (Windows Remote Management), o serviço HTTP* ( %SystemRoot%\system32\drivers\http.sys ) tem sido uma parte padrão do Windows (Vista e posteriormente / Server 2008 e posteriormente). http.sys corre sob o processo System* ( PID 4* ).

3. Outro software desenvolvido pela Microsoft pode também utilizar o %SystemRoot%\system32\drivers\ http.sys* sob o processo System como IIS , SQL Reporting Services , e Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

4. As portas padrão WinRM 1.0 eram:
   HTTP = 80 HTTPS = 443 WinRM 2.0 e maiores são as portas padrão:
   HTTP = 5985 HTTPS = 5986 Verifique com os seguintes comandos:
   Winrm enumerar winrm/config/listener Winrm obter http://schemas.microsoft.com/wbem/wsman/1/config

Passos para a resolução de problemas:

Obtenha o número do processo da porta que procura (443 neste caso):

…de uma unidade não mapeada do Windows para evitar “Acesso Negado”:
netstat -aon | find “:443” Output deve parecer-se com o seguinte para o processo System*:
C:>netstat -ano |find “:443” TCP 0.0.0.0.0:443 0.0.0.0:0 OUVIR 4 TCP [:::]:443 [:::]:0 OUVIR 4 A última coluna é o PID (4).

1. a correr ** lista de tarefas** para descobrir o que está a correr no processo revela-se inútil:
   lista de tarefas /SVC /FI “PID eq 4” lista de tarefas /m /FI “PID eq 4”

2. Procure no registo o serviço HTTP: HKEYLOCALMÁQUINA_SYSTEMSSYSTEMSSITEMSSITITES DE CONTROLO ACTUAL PARÂMETROS UrlAclInfo Haverá uma lista de URLs (com os números das portas) que o podem levar a que aplicação está a correr e a que portas:
   http:// +:5985/wsman/ –> WinRM https:// +:5986/wsman/ –> WinRM http:// +:80/Reports/ –> SQL Reporting Server http:// +: 80/ReportServer/ –> SQL Reporting Server https:// server_fqdn:443/Reports/ –> SQL Reporting Server https:// server_fqdn:443/ReportsServer/ –> SQL Reporting Server http://* : 2869/ –> Simple Service Discovery Protocol service (SSDPSRV) http://* :5357/ –> Web Services Dynamic Discovery (WS-Discovery) https://* : 5358/ –> Web Services Dynamic Discovery (WS-Discovery)

Pode então encontrar o serviço correspondente no sistema e pará-lo e ver que a porta desejada é libertada confirmando com outro comando netstat -aon | find “:443”.

Tive o problema de que a porta 443 era utilizada pelo “sistema” com PID 4 na minha máquina Windows 7. A solução para mim era eliminar uma “Ligação de entrada” (VPN) que existia na pasta de ligações de rede.

Parece que a criei e esqueci de a apagar após a utilização…

Muitas vezes este é o serviço de agente anfitrião VMware (necessário para a comunicação VM-host-to-guest) - vmware-hostd.exe.

Uma boa maneira de descobrir qual o sub-processo que o svchost.exe está a executar é usar Sysinternals’ Process Explorer .

Enfrentei problemas semelhantes com o encaminhamento de 443 pedidos para o meu servidor WAS. Com base nas recomendações desta pergunta, foi o que fiz:

1. a partir de cmd elevado, o prompt correu netstat -a -n -o | findstr 443
2. Identifiquei o PID do processo de escuta no 443
3. Utilizei o Process Explorer para identificar o processo a partir do PID.
4. No meu caso, a escuta da aplicação foi vmwarehostd.exe
5. Parou o servidor da estação de trabalho VMware a partir de services.msc. Reiniciado pelo servidor WAS.

E todos os 443 pedidos chegaram a 443 felizmente para sempre.

PS: Eu já tinha desinstalado o skype que veio construído com a minha instalação do Windows 8. O serviço de encaminhamento e acesso remoto foi desactivado na minha máquina.

Se for um processo iniciado por um serviço, netstat -ab não vai ajudar.

Neste caso, tente netstat -ao | find /i "443" numa linha de comando de administrador. Isto dar-lhe-á uma saída como esta:

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Depois digite tasklist | find /i "<PID>" noutra linha de comando de administrador.

No meu caso o PID era 2912 e o meu comando era:

tasklist | find /i "2912"

A saída do meu comando era:

vmware-hostd.exe 2912 Services 0 39 856 K

Uau, esqueci-me mesmo que instalei o VMware para verificar uma funcionalidade…

No meu caso foi o DataManager da F5 Networks que utiliza Tomcat 6 internamente para servir as suas páginas web. Esqueci-me de desinstalar esse aplicativo. Má decisão de design, se me perguntarem.

No meu caso, foi o processo DTC (Distributed Transaction Coordinator) a utilizar o porto 443. Em particular, activei o WS-AT em DTC, e estava a utilizar a porta 443.

Em geral, compreendo que quando o processo System (PID 4) utiliza a porta 443/HTTPS, é um processo interno do Windows (no meu caso DTC, mas penso que também pode ser outro processo), se não for um website IIS a utilizá-lo.

Utilizando netstat -ao | find ":443", descobri que a porta 443 está a ser utilizada pelo PID 4, que era o processo do Sistema. Isto aconteceu-me duas vezes no Windows Server 2012, e foi devido a uma das seguintes razões:

1. IIS estava a funcionar, listado como “World Wide Web Publishing Service” em Services, que parei.
2. A funcionalidade “Work Folders” foi instalada, pelo que a desinstalei.

Isto pode não ser uma solução para todos, mas pode ajudar alguns.

Descobri que utilizando a funcionalidade VPN no Windows 8 (provavelmente o mesmo para o Windows 7) utilizava a porta 443.

Adicionalmente, a minha porta fechou novamente por PMB.exe (Pando Media Booster).

Para mim, após a actualização do Windows Server 2016, o Apache 443 não pôde começar com o evento habitual listado.

Descobri que o culpado era o Serviço “Windows Sync Sync Share” (SyncShareSvc). Desactivei e consegui iniciar o Apache.

Para mim foi o agente McAfee EPO a ouvir na porta 80. Tive de passar por vários obstáculos dolorosos para o conseguir mudar. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

No meu Windows Server 2019, resolvi-o executando esta PS.

Stop-Service -Name KPSSVC

Funcionou como processo 4 (processo SYSTEM) sob privilégios do Serviço de Rede. Correndo

netstat -ab

não ajudou. Exibiu ‘Não é possível obter informações de propriedade’.

Depois de parar o serviço, netstat -aon | findstr “:443” já não mostra a entrada. Descoberto pela paragem literária de cada serviço, um a um.

KDC Proxy Server service (KPS) - O serviço KDC Proxy Server é executado em servidores de borda para substituir mensagens do protocolo Kerberos a controladores de domínio na rede corporativa.

Wireshark dar-lhe-á os detalhes. http://www.wireshark.org/ Or TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Isso vai ajudar.

Se tiver algum tipo de driver LAN Virtual (como OpenVM, VMware, etc…) - certifique-se de que ‘liberta’ a porta antes de a dar a outra coisa…

Apenas uma pequena dica lateral ;)

Tive o mesmo problema ao tentar instalar uma actualização VMware. Localizei-a no Skype. O novo cliente tem por defeito 443.