El síntoma: «Bing dice que la conexión no es privada»
El cliente abría Edge, entraba a Bing y recibía la pantalla roja: «La conexión no es privada» – ERR_CERT_AUTHORITY_INVALID. Lo raro era que YouTube, Kahoot y la mayoría de sitios cargaban bien. Solo algunos, Bing entre ellos, se negaban.
Y había un antecedente que lo volvía más sospechoso: meses atrás ya le había pasado. En aquel momento encontró que un activador de Office (AutoKMS / KMSpico) había instalado un certificado "raro" en Windows. Lo borró, el error desapareció… y ahora había vuelto.
Ese "volvió" es la primera pista importante: cuando un problema regresa solo, no es un residuo, es algo que se está reinstalando.
Qué significa ese error (y por qué no hay que saltárselo)
Cuando entras a un sitio con HTTPS, el sitio te muestra un certificado firmado por una autoridad en la que tu Windows confía. Si el certificado que llega no lo firmó nadie de confianza, el navegador te frena. Las dos explicaciones posibles son:
- A tu Windows le falta alguna autoridad de confianza (raro, pero pasa).
- Alguien se puso en medio y te está entregando un certificado propio en lugar del real.
Por eso el botón "Avanzado → Continuar" es mala idea: si es el caso 2, estarías aceptando hablar con el intermediario.
El diagnóstico: lo que parecía y no era
Vale la pena contar el camino completo, porque enseña más que la respuesta final. Fueron varias hipótesis, y varias se cayeron con la evidencia.
Primera revisión, todo de solo lectura. Proxy de Windows, certificados raíz recientes, tareas programadas, procesos escuchando en el equipo y archivo hosts:
netsh winhttp show proxy
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
Select-Object ProxyEnable, ProxyServer, AutoConfigURL
Get-ChildItem Cert:\LocalMachine\Root | Sort-Object NotBefore -Desc |
Select-Object -First 12 Subject, NotBefore
Get-ScheduledTask | Where-Object { $_.TaskName -match 'KMS|Activat|AutoPico' } |
Select-Object TaskName, State
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalAddress -match '127.0.0.1|0.0.0.0' } |
Select-Object LocalPort, @{n='Proceso';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
Sort-Object LocalPort -Unique
Resultado: sin proxy configurado en Windows, certificados raíz todos legítimos, hosts limpio. Pero dos cosas sí aparecieron:
TaskName State
KMSpico Auto Update Scheduler Running
LocalPort Proceso
83 kmsupd
86 kmsupd
Una tarea programada de KMSpico activa y un proceso suyo, kmsupd.exe, escuchando en los puertos 83 y 86 del propio equipo. Ahí estaba la persistencia que lo traía de vuelta.
Lo que descartamos por el camino, cada cosa con la prueba que la tumbó:
Todo eso dejó una contradicción muy clara: Windows validaba bien el certificado de Bing y curl cargaba la página, pero Edge no. Mismo equipo, misma red. Entonces el problema tenía que estar en un camino que solo usaba el navegador.
La causa real: el activador se había puesto de proxy
La prueba reversible fue deshabilitar la tarea y matar el proceso:
Stop-ScheduledTask -TaskName 'KMSpico Auto Update Scheduler'
Disable-ScheduledTask -TaskName 'KMSpico Auto Update Scheduler'
Stop-Process -Name kmsupd -Force
Al recargar Bing, el error cambió. Ya no era de certificado: ERR_PROXY_CONNECTION_FAILED. Edge se había quedado "sin internet" porque estaba configurado para salir por un proxy en 127.0.0.1, y ese proxy era kmsupd.exe. Al matarlo, el navegador no tenía por dónde salir.
Eso lo explica todo:
- El activador instaló un proxy local y un certificado raíz propio. Mientras ese certificado estuvo en Windows, el navegador "confiaba" en el intermediario y todo parecía funcionar. Era peor, no mejor: todo el tráfico HTTPS del navegador pasaba abierto por ese programa.
- Cuando el cliente borró el certificado, el proxy siguió ahí, pero Windows ya no confiaba en lo que entregaba. De ahí el error.
- Las comprobaciones "salían limpias" porque buscábamos el proxy donde lo guarda Windows, y el navegador usaba la configuración de proxy del sistema que el activador había puesto por su cuenta.
Por qué solo algunos sitios: los que usan ciertas cadenas de certificados o que el navegador protege con más rigor (como los de Microsoft) son los primeros en romperse. Que "casi todo cargue" no significa que no haya nadie en medio.
La solución, paso a paso
Antes de empezar: todo lo de abajo se ejecuta en PowerShell como administrador. Los pasos 1 y 2 son reversibles; el 4 mueve a cuarentena en lugar de borrar, justo para poder volver atrás si algo dependiera de ello.
Paso 1. Apagar lo que lo revive
Stop-ScheduledTask -TaskName 'KMSpico Auto Update Scheduler' -EA 0
Disable-ScheduledTask -TaskName 'KMSpico Auto Update Scheduler' -EA 0
Stop-Process -Name kmsupd -Force -EA 0
Get-NetTCPConnection -State Listen -LocalPort 83,86 -EA 0 # debe salir vacío
Si no sale nada en la última línea, el proxy ya no está escuchando.
Paso 2. Quitar el proxy del navegador
Abre Configuración de Windows → Red e Internet → Proxy (o en Edge pega edge://settings/system y pulsa "Abrir configuración del proxy del equipo"). En Configuración manual del proxy verás "Usar un servidor proxy" activado con 127.0.0.1 y el puerto 83 u 86. Desactívalo y activa "Detectar la configuración automáticamente". Cierra Edge por completo y vuelve a abrirlo.
Paso 3. Probar
Recarga el sitio que fallaba con Ctrl + Shift + R. Debe cargar sin aviso. Sin proxy no hay intermediario, y sin intermediario no hay certificado falso.
Paso 4. Cuarentena en vez de borrado
Primero mira qué hay y si existe desinstalador oficial:
Get-ChildItem 'C:\Program Files (x86)\Common Files\KMSpico' -Recurse -EA 0 | Select-Object FullName, Length
(Get-MpPreference).ExclusionPath # ¿se metió como exclusión en Defender?
(Get-MpPreference).ExclusionProcess
En este caso quedaba solo la carpeta con kmsupd.exe (81 KB), sin servicio, sin desinstalador y, por suerte, sin exclusiones en Defender. Entonces:
Get-Process kmsupd -EA 0 | Stop-Process -Force -EA 0
New-Item -Path 'C:\Cuarentena_KMS' -ItemType Directory -Force | Out-Null
Move-Item 'C:\Program Files (x86)\Common Files\KMSpico' 'C:\Cuarentena_KMS\KMSpico' -Force
Rename-Item 'C:\Cuarentena_KMS\KMSpico\Update\kmsupd.exe' 'kmsupd.exe.bak' -EA 0
Unregister-ScheduledTask -TaskName 'KMSpico Auto Update Scheduler' -Confirm:$false -EA 0
Si en tu caso Defender tenía exclusiones apuntando a esa carpeta, quítalas: con la exclusión puesta, el antivirus está ciego justo donde vive el problema.
Paso 5. Reiniciar y verificar
Test-Path 'C:\Program Files (x86)\Common Files\KMSpico' # False
Get-ScheduledTask -TaskName 'KMSpico*' -EA 0 # vacío
Get-NetTCPConnection -State Listen -LocalPort 83,86 -EA 0 # vacío
Si tras reiniciar los tres siguen vacíos, no volvió. Pasados unos días sin novedad, borra C:\Cuarentena_KMS.
Paso 6. Escaneo completo y cambio de contraseñas
Escaneo completo con Windows Defender. Y esto es lo que más cuesta aceptar: mientras ese certificado estuvo confiado, todo lo que pasó por el navegador fue legible para ese programa: correos, banca, paneles de administración, contraseñas. No hay forma de saber qué hizo con eso. Lo prudente es cambiar las contraseñas de todo lo que usaste desde ese equipo, empezando por correo y banca.
El efecto secundario: la activación
Al apagar el activador, el Office que dependía de él va a reclamar en unos días. En este caso, Windows Pro y un Office 2021 tenían licencia propia y no se vieron afectados; solo una instalación de Office "KMS" quedó sin activar.
Aquí no te vamos a decir cómo volver a activarlo por la vía pirata, porque el activador es exactamente lo que te metió el intermediario. "Sin riesgo" no existe en esa familia de programas. Lo que sí hay:
- Office en la web, gratis con una cuenta Microsoft: Word, Excel, PowerPoint y Outlook en el navegador.
- LibreOffice u OnlyOffice, gratis en el escritorio, abren y guardan
.docxy.xlsx. - Microsoft 365 Business Basic, unos pocos dólares por usuario al mes, con correo de dominio propio incluido. Un año cuesta menos que una sola contraseña robada.
Qué aprender de esto
- Si un problema vuelve solo, busca la tarea programada. Borrar el síntoma (el certificado) no sirve si algo lo reinstala.
- "Solo falla en el navegador" es una pista, no una rareza. Compara con
curlo PowerShell: si ellos pasan y el navegador no, hay un proxy o extensión en medio. - Un activador pirata no es "gratis". Este tenía un proxy leyendo todo el tráfico. Es el precio.
- El aviso rojo del certificado te está protegiendo. No lo saltes.
- Después de un intermediario confirmado, se cambian contraseñas. No es paranoia: ya sabemos que estuvo ahí.
Si tu equipo muestra avisos de certificado que van y vienen, o un programa que "se reinstala solo", mejor no adivinar: tráelo o escríbenos y lo revisamos con el mismo método de arriba, sin tocar nada hasta saber qué es.