2010-03-29 18:35:17 +0000 2010-03-29 18:35:17 +0000
46
46

¿Por qué el proceso 'System' escucha en el puerto 443?

Estoy teniendo problemas para iniciar mi servidor Apache, porque el puerto 443 ya está en uso.

Resulta que el proceso del sistema (PID 4) utiliza el puerto 443. No tengo IIS instalado, el services.msc muestra (como era de esperar) que no se está ejecutando ningún servidor Exchange, ni WWW-Services, ni IIS. No tengo ni idea de cómo averiguar qué servicio utiliza ese puerto, a no ser que desactive cada servicio uno tras otro, y ni siquiera estoy seguro de que eso sirva.

Agradecería que alguien me indicara cómo puedo recuperar mi puerto SSL, gracias :)

P.D.: Por supuesto que “simplemente cambiar Apache a otro puerto para SSL” solucionaría el problema de no poder iniciar Apache. Pero igual me gustaría saber qué es lo que insiste en acaparar el puerto 443. :)

  • *

Por ahora tomé el “camino difícil” y desactivé los servicios uno tras otro. Resultó que el servicio “Routing and RAS” era el culpable.

Gracias a todos por las valiosas aportaciones y las nuevas herramientas en el combate contra el “¿Qué hace mi sistema ahora?”.
Fuente

Respuestas (17)

32
32
32
2010-03-29 18:40:13 +0000

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

Fuente
18
18
18
2010-03-29 18:41:24 +0000

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

netstat -ab
Fuente
14
14
14
2017-09-08 00:02:56 +0000

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:// server    fqdn: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”.
Fuente
11
11
11
2014-03-13 17:45:42 +0000
Fuente
7
7
7
2012-10-05 20:57:27 +0000

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 .
Fuente
6
6
6
2013-11-11 19:56:01 +0000

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.
Fuente
4
4
4
2016-02-09 11:35:33 +0000

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…
Fuente
1
1
1
2011-02-18 20:46:53 +0000

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.
Fuente
1
1
1
2010-10-04 12:38:54 +0000

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.
Fuente
1
1
1
2016-05-19 19:12:23 +0000

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.
Fuente
0
0
0
2013-04-23 20:38:42 +0000

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).
Fuente
0
0
0
2018-04-19 13:49:36 +0000

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.
Fuente
0
0
0
2014-05-14 11:37:14 +0000

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

Fuente
0
0
0
2020-01-23 14:32:45 +0000

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.
Fuente
-1
-1
-1
2010-03-29 18:44:25 +0000

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

Eso ayudará.
Fuente
-1
-1
-1
2011-09-29 08:20:02 +0000

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 ;)
Fuente
-2
-2
-2
2013-11-19 17:02:47 +0000

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