Seguro que es Skype. Desmarca la casilla que se muestra a continuación si lo tienes instalado.

Ejecute lo siguiente desde un símbolo del sistema elevado:

netstat -ab

En primer lugar, voy a responder a esta pregunta directamente y cualquiera que lea esto puede ignorar cualquier respuesta que hable de aplicaciones de terceros, no de Microsoft, que utilicen el proceso System.

1. El proceso System aparece como PID 4 en todos los sistemas Windows actuales. Es para el acceso en modo kernel. Esto descarta la mayoría de los productos web de terceros como Apache.

2. Desde el inicio de WinRM (Windows Remote Management), el servicio HTTP ( %SystemRoot%\system32\drivers\http.sys ) ha sido una parte estándar de Windows (Vista y posterior / Server 2008 y posterior). http.sys se ejecuta bajo el proceso System ( PID 4 ).

3. Otro software desarrollado por Microsoft también puede utilizar el %SystemRoot%\system32\drivers** bajo el proceso System como IIS , SQL Reporting Services , y Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

4. Los puertos por defecto de WinRM 1.0 eran
   HTTP = 80 HTTPS = 443 Los puertos por defecto de WinRM 2.0 y superiores son:
   HTTP = 5985 HTTPS = 5986 Compruebe con los siguientes comandos:
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Pasos para solucionar problemas:

Obtener el número de proceso del puerto que se busca (443 en este caso):

…desde una unidad no mapeada de Windows para evitar el “Acceso denegado”:
netstat -aon | find “:443” La salida debería ser la siguiente para el proceso System:
C:>netstat -ano |find “:443” TCP 0.0.0.0:443 0.0.0:0 LISTENING 4 TCP [::]:443 [::]:0 LISTENING 4 La última columna es el PID (4).

1. Ejecutar tasklist para averiguar qué se está ejecutando en el proceso no resulta útil:
   tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

2. Busque en el registro el servicio HTTP: HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo Habrá una lista de URLs (con los números de los puertos) que puede llevarle a saber qué aplicación se está ejecutando y qué puertos:
   http:// +:5985/wsman/ –> WinRM https:// +:5986/wsman/ –> WinRM http:// +:80/Reports/ –> SQL Reporting Server http:// +: 80/ReportServer/ –> SQL Reporting Server https:// serverfqdn:443/Reports/ –> SQL Reporting Server https:// server_fqdn:443/ReportsServer/ –> SQL Reporting Server http://* : 2869/ –> Servicio de protocolo de descubrimiento de servicios simples (SSDPSRV) http://* :5357/ –> Descubrimiento dinámico de servicios web (WS-Discovery) https://* : 5358/ –> Web Services Dynamic Discovery (WS-Discovery)

A continuación, puede encontrar el servicio correspondiente en el sistema y detenerlo y ver que el puerto deseado está liberado confirmándolo con otro comando netstat -aon | find “:443”.

A menudo se trata del servicio de agente del host de VMware (necesario para la comunicación entre el host y la máquina virtual) - vmware-hostd.exe.

Una buena manera de averiguar qué subproceso svchost.exe se está ejecutando es utilizar el Process Explorer .

Me enfrenté a problemas similares con el enrutamiento de las solicitudes 443 a mi servidor WAS. Basado en las recomendaciones de esta pregunta, esto es lo que hice:

1. Desde el prompt de cmd elevado ejecuté netstat -a -n -o | findstr 443
2. Identificar el PID del proceso que escucha en 443
3. Usé el Explorador de Procesos para identificar el proceso a partir del PID.
4. En mi caso la aplicación que escuchaba era vmwarehostd.exe
5. Detenido el servidor VMware Workstation de services.msc. 6. Reiniciado el servidor WAS.

Y todas las peticiones 443 llegaron a 443 felizmente.

PD: Ya había desinstalado skype que venía incorporado con mi instalación de Windows 8. El servicio de enrutamiento y acceso remoto estaba desactivado en mi máquina.

Si se trata de un proceso iniciado por un servicio, netstat -ab no ayudará.

En este caso intente netstat -ao | find /i "443" en una línea de comandos de administrador. Esto le dará una salida como esta

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Luego escriba tasklist | find /i "<PID>" en otra línea de comandos de administrador.

En mi caso el PID era 2912 y mi comando fue:

tasklist | find /i "2912"

La salida de mi comando fue:

vmware-hostd.exe 2912 Services 0 39 856 K

Vaya, hasta se me ha olvidado que instalé VMware para comprobar una funcionalidad…

En mi caso era DataManager de F5 Networks que usa Tomcat 6 internamente para servir sus páginas web. Me olvidé de desinstalar esa aplicación. Una mala decisión de diseño, en mi opinión.

En mi caso era el proceso DTC (Distributed Transaction Coordinator) el que utilizaba el puerto 443. En concreto, activé WS-AT en DTC, y estaba usando el puerto 443.

En general, entiendo que cuando el proceso System (PID 4) utiliza el puerto 443/HTTPS, es un proceso interno de Windows (en mi caso DTC, pero creo que también puede ser otro proceso), si no es un sitio web de IIS el que lo utiliza.

Usando netstat -ao | find ":443", descubrí que el puerto 443 está siendo utilizado por el PID 4, que era el proceso System. Esto me pasó dos veces en Windows Server 2012, y se debió a una de las siguientes razones:

1. Se estaba ejecutando IIS, que figuraba como “World Wide Web Publishing Service” en Servicios, que detuve.
2. La función Work Folders se instaló, así que la desinstalé.

Puede que esto no sea una solución para todos, pero puede ayudar a algunos.

Encontré que el uso de la funcionalidad VPN en Windows 8 (probablemente el mismo para Windows 7) utiliza el puerto 443.

Además, mi puerto se cerró de nuevo por PMB.exe (Pando Media Booster).

Para mí, después de la actualización de Windows Server 2016, Apache 443 no pudo iniciar con evento habitual enumerado.

Encontré que el culpable era el servicio “Windows Sync Share” (SyncShareSvc). Desactivé y pude iniciar Apache.

En mi caso era el agente de McAfee EPO que escuchaba en el puerto 80. Tuve que pasar por varios aros dolorosos para conseguir cambiarlo. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

En mi Windows Server 2019, lo solucioné ejecutando este PS.

Stop-Service -Name KPSSVC

Se ejecutó como proceso 4 (proceso SYSTEM) bajo privilegios de Servicio de Red. Ejecutar

netstat -ab

no ayudó. Aparece el mensaje “No se puede obtener información sobre la propiedad”.

Después de detener el servicio, netstat -aon | findstr “:443” ya no muestra la entrada. Lo descubrí deteniendo literariamente cada servicio uno por uno.

KDC Proxy Server service (KPS) - El servicio KDC Proxy Server se ejecuta en los servidores de borde para enviar por proxy los mensajes del protocolo Kerberos a los controladores de dominio en la red corporativa.

Wireshark le dirá los detalles. http://www.wireshark.org/ O TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Eso ayudará.

Si tienes algún tipo de controlador de LAN virtual (como OpenVM, VMware, etc.) - asegúrate de ‘liberar’ el puerto antes de dárselo a otra cosa…

Sólo un consejo rápido ;)

Tuve el mismo problema al intentar instalar una actualización de VMware. Lo localicé en Skype. El nuevo cliente por defecto a 443.