Certificado TLS expirado o mal configurado TLS certificate expiry / misconfiguration

ID de la causa in-cert · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Si el certificado de un servidor de login, de API o de parches expira o le falta el certificado intermedio, desde ese momento falla la conexión TLS de los clientes que abren una conexión nueva.

Por qué El certificado está fuera de su periodo de validez, el servidor lo envía sin el certificado intermedio, o la fecha y hora del dispositivo del jugador están mal → Efecto El cliente no puede validar el certificado y corta la conexión TLS → En pantalla El juego no conecta o se queda en carga infinita en el login o la descarga de parches, fallan solo las funciones HTTPS como la tienda. Quienes ya estaban conectados suelen seguir bien

Síntomas: No conecta / carga infinita, Acción perdida / rollback
Factores: Detención
A quién afecta: Todo el servidor, Solo una función, Solo yo
Cuándo: Al conectar o tras un mantenimiento, Al hacer ciertas acciones
Responsable: Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Registrar los errores de certificado con un código distinto del de otros fallos de conexión y mostrar un aviso; si el error es de fecha, indicar que se active el ajuste automático de fecha y hora del dispositivo; si se usa fijación de certificados (pinning), incluir también claves de respaldo y coordinar con el equipo de infraestructura el calendario de cambio de certificados.
Tareas (Equipo de infraestructura): Red: si TLS termina en el balanceador de carga o la CDN, poner alertas sobre el estado de la renovación automática de los certificados gestionados y los días que quedan (DaysToExpiry en ACM), mantener los registros DNS de validación. Servidores/SO: si TLS termina en el servidor, automatizar la renovación y recargar la configuración después, configurar la cadena incluyendo el certificado intermedio, comprobar periódicamente desde fuera la validez restante de cada dirección de login, API y parches, y poner alertas.
Cifras de referencia: Los certificados de Let’s Encrypt duran 90 días y se recomienda renovarlos cada 60, y AWS Certificate Manager comprueba los certificados validados por DNS 45 días antes de que expiren y los renueva automáticamente. Si la renovación automática falla en silencio, las conexiones nuevas se bloquean todas a la vez justo a la hora de la expiración.
En el gráfico: Desconexión masiva · Inicios de sesión exitosos, errores de handshake TLS
Dónde mirar: Ver con openssl s_client -connect HOST:443 -showcerts la lista de certificados que envía realmente el servidor y comprobar la fecha de expiración (notAfter) de cada uno con openssl x509 -noout -enddate. Si TLS termina en el balanceador de carga, errores de negociación TLS (ClientTLSNegotiationErrorCount en AWS ALB y NLB) e inicios de sesión exitosos
Se confirma si: La fecha de expiración ya pasó o falta el certificado intermedio en la lista que envía el servidor, y los errores empiezan a subir a la hora en que expiró o se cambió el certificado
Se descarta si: Si la lista de certificados y la fecha de expiración están bien pero solo fallan algunos jugadores, revisar la fecha y hora de sus dispositivos o la lista de certificados raíz de un SO antiguo
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)
Para saber más: Una configuración a la que le falta el certificado intermedio puede parecer correcta al abrirla en un navegador de PC. El navegador recuerda certificados intermedios que obtuvo en otros sitios y completa el hueco, pero los clientes sin esa memoria, como las apps de Android, fallan. Además, la validez se está acortando. Let’s Encrypt prevé reducir la validez predeterminada a 64 días en 2027 y a 45 días en 2028, así que una configuración fija de renovar cada 60 días solo deja cuatro días de margen con certificados de 64 días, y con los de 45 días se pasa de la fecha de expiración. AWS Certificate Manager tampoco renueva automáticamente los certificados importados, y si se borran los registros DNS de validación la renovación falla. El bloqueo del login se parece al de “Fallos y lentitud del DNS”, pero un problema de certificado falla en el handshake TLS, después de encontrar la dirección del servidor, y empieza a la misma hora en que expiró o se cambió el certificado.

Fuentes

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF
La validez de un certificado va de notBefore a notAfter; la validación de la ruta comprueba, para cada certificado de la cadena, que la hora actual está dentro de su validez (si el reloj de quien valida está mal, falla)
FAQ Let's Encrypt
Validez predeterminada del certificado: 90 días; se recomienda renovar cada 60 días
Decreasing Certificate Lifetimes to 45 Days Let's Encrypt
La validez predeterminada se reduce a 64 días desde febrero de 2027 y a 45 días desde febrero de 2028; renovar a intervalos fijos de 60 días deja de bastar y se recomienda renovar hacia los dos tercios de la validez
Renewal for domains validated by DNS AWS
45 días antes de la expiración comprueba si el certificado está en uso en un servicio de AWS y si existe el registro CNAME de validación, y lo renueva automáticamente; si no puede validarlo, avisa 30, 15, 7, 3 y 1 días antes de la expiración
Managed certificate renewal in AWS Certificate Manager AWS
Los certificados importados y los ya expirados no se renuevan automáticamente
Supported CloudWatch metrics AWS
DaysToExpiry: días que faltan para que expire el certificado; se publica dos veces al día hasta la expiración
Security with network protocols Android (Google)
Si el servidor envía la cadena sin el certificado intermedio, las apps de Android fallan con SSLHandshakeException, pero un navegador de PC puede completarla con certificados intermedios ya obtenidos y no dar error; la cadena que envía el servidor se comprueba con openssl s_client
Network security configuration Android (Google)
Con fijación de certificados (pinning) hay que incluir claves de respaldo para prepararse ante cambios de clave o de CA; si no, las conexiones se cortan hasta que se actualiza la app
openssl-s_client OpenSSL
-showcerts: muestra la lista de certificados que envió el servidor, en el orden en que los envió (no es la cadena validada)
openssl-x509 OpenSSL
-enddate: muestra la fecha de expiración del certificado (notAfter); -checkend: comprueba si expira dentro de los segundos indicados
CloudWatch metrics for your Application Load Balancer AWS
ClientTLSNegotiationErrorCount: número de conexiones que no pudieron establecer una sesión TLS, por ejemplo porque el cliente no pudo validar el certificado del servidor y cortó la conexión
CloudWatch metrics for your Network Load Balancer AWS
ClientTLSNegotiationErrorCount: número de handshakes TLS en los que falló la negociación entre el cliente y el listener TLS

Ver también

Misma capa: L13 Arquitectura y operación de servidores

Causas de otras capas con el mismo síntoma (No conecta / carga infinita)

Inspección de paquetes del software de seguridad L2 SO y dispositivo del cliente
Router poco potente o sobrecalentado L3 Red doméstica
Restricciones en Wi-Fi público y redes corporativas L3 Red doméstica
Restricciones de UDP e inspección de paquetes por país o ISP L4 Ruta por internet
Fallos y lentitud del DNS L4 Ruta por internet
Enlaces compartidos saturados por un DDoS L4 Ruta por internet
IP compartida del ISP (CGNAT) L4 Ruta por internet
Paso por una VPN o un acelerador de juegos L4 Ruta por internet

Ver la ficha interactiva con gráficos y simulaciones