Cómo un reloj del sistema mal puesto rompe TLS y la licencia
Cómo un reloj mal puesto rompe la validación TLS y todas las comprobaciones de licencia que dependen de ella, cómo funciona la sincronización de hora de Windows, qué comandos fuerzan una resincronización y de dónde sale el desfase del reloj en arranque dual.
Respuesta corta
Cuando el reloj local queda fuera de la ventana de fechas de un certificado, TLS rechaza un certificado válido y toda comprobación de licencia por HTTPS falla. Arregla primero el reloj con w32tm /resync, antes de generar claves nuevas, reinstalar el loader o tocar reglas del firewall.
En esta página8
- ¿Por qué un certificado depende de tu reloj?
- Por qué un reloj mal puesto parece un problema de licencia
- ¿Cómo funciona la sincronización de hora de Windows?
- Comandos para comprobar y arreglar la sincronización de hora
- Cómo forzar una resincronización de la hora
- Por qué el reloj se va horas enteras después de cada reinicio
- Problemas causados por un reloj mal puesto
- Preguntas frecuentes sobre el reloj del sistema
¿Por qué un certificado depende de tu reloj?
Todo certificado TLS lleva dos marcas de tiempo, not-before y not-after, y cuando tu máquina abre una conexión HTTPS las compara con su propio reloj. Si la hora local cae fuera de esa ventana, el certificado se rechaza y la conexión falla antes de que se intercambie ningún dato. No hay forma de esquivarlo, porque esa comprobación es justo el sentido de una ventana de validez. Una máquina cuyo reloj marca el año pasado rechazará un certificado perfectamente válido, y una cuyo reloj marca el año que viene, también.
Por qué un reloj mal puesto parece un problema de licencia
El tráfico de licencia y activación va por HTTPS, así que cuando el reloj está mal, el handshake TLS falla. La aplicación informa entonces de lo que le diga su ruta de error: clave no válida, fallo de autenticación, no se ha podido contactar con el servidor o respuesta inesperada. Ninguno de esos mensajes menciona el reloj, así que la gente se pasa una tarde regenerando claves y reinstalando un loader para arreglar un problema de dos minutos. Algunos servicios además firman las peticiones con una marca de tiempo y rechazan todo lo que quede fuera de una ventana de tolerancia, y eso falla igual aunque el TLS sí pase.
¿Cómo funciona la sincronización de hora de Windows?
Windows lleva la hora con un servicio llamado Hora de Windows, o w32time, que habla NTP con un servidor configurado. No corrige el reloj de forma continua: se despierta cada cierto intervalo, le pide la hora actual a un servidor de tiempo y se ajusta. En la práctica lo rompen tres cosas. El servicio puede estar parado o puesto en inicio manual, y entonces no se sincroniza nunca. El servidor configurado puede ser inalcanzable, algo habitual en una red restringida o detrás de un firewall agresivo. O la máquina puede ir tan desviada que Windows considere la corrección inverosímil y se niegue a dar un salto tan grande. Los tres casos se ven igual: el interruptor de Configuración parece correcto, pero el reloj sigue mal.
Comandos para comprobar y arreglar la sincronización de hora
Ejecútalos en un símbolo del sistema como administrador y en este orden. La consulta de estado va primero porque te dice si el problema está en el servicio, en el servidor o en el desfase.
w32tm /query /status
w32tm /query /source
w32tm /query /configuration
net start w32time
w32tm /resync
w32tm /resync /rediscover
w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly
w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:MANUAL /update
sc config w32time start= autoCómo forzar una resincronización de la hora
Empieza por el segundo PC, porque ahí es donde se autentica, y luego repítelo en el PC de juego si una nota del producto lo pide.
- Abre Configuración, Hora e idioma, Fecha y hora, y confirma que la zona horaria es la correcta, porque la hora buena en la zona equivocada sigue siendo un reloj mal puesto
- Desactiva Establecer la hora automáticamente, vuelve a activarlo y pulsa Sincronizar ahora
- Si no cambia nada, abre un símbolo del sistema como administrador
- Ejecuta w32tm /query /status y lee la hora de la última sincronización correcta y el origen
- Si el servicio no está en marcha, ejecuta net start w32time y luego ponlo en inicio automático con sc config
- Ejecuta w32tm /resync y lee el resultado, que o bien informa de que ha ido bien o bien dice por qué ha fallado
- Si el servidor es inalcanzable, fija uno concreto con el comando de configuración y vuelve a sincronizar
- Vuelve a contrastar el reloj con cualquier otro dispositivo y reintenta la comprobación de licencia antes de cambiar nada más
Aviso
Por qué el reloj se va horas enteras después de cada reinicio
Este problema parece una avería de hardware, pero no lo es. Windows guarda el reloj del hardware en hora local, mientras que Linux y macOS lo guardan por convención en UTC. En una máquina con arranque dual, cada sistema operativo corrige ese mismo reloj compartido según su propia convención, así que cada reinicio desplaza la hora tu desfase respecto a UTC. Lo mismo pasa con una máquina virtual cuyo anfitrión e invitado no se ponen de acuerdo, o cuando las herramientas del sistema invitado sincronizan contra un anfitrión que va mal él mismo. El síntoma es un reloj que se desvía un número exacto de horas enteras, se restablece después de cada arranque y parece ignorar una sincronización correcta. Arregla la convención o el anfitrión, no el reloj.
Problemas causados por un reloj mal puesto
Comprueba el reloj antes de meterte con arreglos más largos, porque la comprobación lleva treinta segundos y no cuesta nada.
| Síntoma | Causa probable | Solución |
|---|---|---|
| Licencia no válida, clave rechazada o fallo de autenticación con una clave válida | La validación TLS ha fallado porque el reloj local queda fuera de la ventana de validez del certificado | Ejecuta w32tm /query /status y luego w32tm /resync, confirma el reloj y la zona horaria, y reintenta antes de regenerar nada |
| Errores de certificado en el navegador de esa misma máquina | Es la confirmación de que la causa es el reloj y no la aplicación | Arregla primero el reloj, porque si el navegador tampoco puede abrir un sitio HTTPS normal, ninguna aplicación de esa máquina va a autenticarse |
| Sincronizar ahora no hace nada y el reloj sigue mal | El servicio Hora de Windows está parado o puesto en inicio manual | Ejecuta net start w32time, ponlo en inicio automático con sc config y vuelve a sincronizar |
| La resincronización dice que el servidor es inalcanzable | El servidor de tiempo configurado está bloqueado o su nombre no se resuelve en esta red | Fija un servidor concreto y alcanzable con el comando manualpeerlist y sincroniza, y luego confirma que ninguna política del router esté bloqueando el NTP saliente |
| El reloj se desvía exactamente una o varias horas enteras y se restablece en cada arranque | Choque entre la convención UTC y la de hora local en arranque dual o en una máquina virtual | Haz que los dos sistemas usen la misma convención para el reloj del hardware o arregla el reloj del propio anfitrión, porque corregir solo el invitado no aguanta |
| El reloj se desvía mucho en una máquina que está a menudo sin conexión | No hay ocasión de sincronizar y, en hardware antiguo, una pila de respaldo gastada | Conéctala y sincroniza antes de cada sesión, y si además olvida la fecha mientras está apagada, cámbiale la pila a la placa |
Preguntas frecuentes sobre el reloj del sistema
¿Cuánto se tiene que desviar el reloj para que algo se rompa?
Para TLS, lo bastante como para salirse de la ventana de validez de un certificado, y eso pueden ser días. Para la firma de peticiones, algunos servicios rechazan desfases de solo unos minutos, así que da por bueno arreglar cualquier cosa por encima de un minuto más o menos.
¿El reloj de qué máquina importa?
El de la que autentica, que normalmente es el segundo PC, así que sincroniza ese primero. Sincroniza también el PC de juego si una nota del producto lo pide o si le están fallando sus propios servicios en línea.
¿Basta con poner la hora a mano?
Ponerla a mano te desbloquea al momento, pero el reloj se volverá a desviar, así que arregla la sincronización para que se mantenga correcto. Comprueba la zona horaria además de la hora que se muestra.
¿Puede un reloj mal puesto provocar fallos de lectura o errores de DTB?
No. El reloj afecta a TLS, a las licencias y a todo lo que firme una marca de tiempo. Los fallos de lectura y los errores de DTB pertenecen a otra capa: el USB, el mapa de memoria o la compilación de Windows.
¿Cambiar la zona horaria cambia el reloj?
Cambia la hora local que se muestra, no el momento real, así que una máquina puede enseñar una hora local equivocada con el reloj perfectamente sincronizado. Eso sigue rompiendo todo lo que compare marcas de tiempo locales, así que pon también la zona bien.
Fuentes
Ninguna de las fuentes consultadas cubre la comprobación de la hora en TLS ni la sincronización de hora de Windows, así que el material se apoya en administración de Windows corriente y en los tickets de licencia de la propia tienda.
Sigue leyendo
¿Sigues atascado? Abre un ticket en Discord
Todas las guías