Un certificado es una afirmación fechada. Dice que en un momento dado un dominio estaba controlado por la parte nombrada en él, que un par de claves pertenece a esa parte y que una autoridad de certificación comprobó ambas cosas. Los navegadores y las bibliotecas de internet tratan después esa afirmación como utilizable hasta la fecha de caducidad impresa dentro de ella, y por eso la duración de esa fecha siempre ha sido un parámetro operativo y no una nota a pie de página jurídica.
Para una plataforma de juego el parámetro acaba de cambiar dos veces, y un tercer cambio tiene un calendario publicado. Un certificado que debe sustituirse cada 200 días —y más adelante cada 47— no es una tarea de renovación que pueda vivir en un calendario trimestral con un recordatorio puesto con un mes de antelación. Es un ciclo de vida que tiene que estar guiado por un inventario, automatizado, monitorizado y documentado con evidencia, porque el modo de fallo no es un aviso en un registro: son jugadores que no pueden abrir el sitio en absoluto.
El calendario, en palabras del documento que lo fija
Los Requisitos Base de TLS del CA/Browser Forum son el reglamento común que los navegadores y las autoridades de certificación públicas acuerdan seguir. La sección 6.3.2 fija el periodo de validez máximo de un certificado de suscriptor de confianza pública y, desde el 15 de marzo de 2026, dice lo siguiente para el tramo actual: un certificado emitido el 2026-03-15 o después, y antes del 2027-03-15, «NO DEBERÍA tener un Periodo de Validez superior a 199 días y NO DEBE tener un Periodo de Validez superior a 200 días». La misma sección continúa hasta 100 días desde el 2027-03-15 y 47 días desde el 2029-03-15, y define un día a efectos de cálculo como 86.400 segundos, añadiendo que los certificados no deberían emitirse por el tiempo máximo permitido de forma predeterminada, para que los segundos fraccionarios y los segundos intercalares no empujen un valor por encima del límite.
La votación que fijó ese calendario merece leerse por su razonamiento y no solo por su tabla. La balota SC-081v3 fue propuesta por Clint Wilson, de Apple, respaldada por Sectigo, Google Chrome y Mozilla, y salió adelante con 25 votos de emisores de certificados a favor y ninguno en contra, más los cuatro votos de consumidores. Su propio resumen del cambio es rotundo: una reducción final de la validez máxima de 398 días a 47 días, con las reducciones «previstas para comenzar en marzo de 2026 y concluir en marzo de 2029». Su primer beneficio declarado es la frase que merece pegarse a la pared —los certificados «son representaciones de un estado de la realidad en un momento concreto»—, seguida de la observación de que cuanto más vive un certificado, más probable es que su contenido se haya alejado de la realidad.
Dos párrafos de esa balota importan a un equipo de plataforma de una forma que una tabla de fechas no logra. El primero es su alcance: los Requisitos Base «abordan requisitos únicamente para certificados que están “destinados a usarse para autenticar servidores accesibles a través de Internet”». Una CA privada dentro de tu propio entorno no se rige por este calendario, lo cual es una decisión que ahora hay que tomar de forma deliberada, porque el calendario público arrastrará tus endpoints públicos a una cadencia mucho más rápida que la de los internos, y una plataforma que trate ambos por igual automatizará de más un servicio interno de bajo riesgo o de menos uno público. El segundo es un recordatorio sobre la revocación: los requisitos ya obligan a una CA a revocar un certificado en un plazo de 24 horas en determinadas circunstancias, y la balota señala que la gestión práctica de los certificados no siempre ha reflejado la expectativa de poder sustituir uno en el plazo de un día.
Qué más cambió con él
El periodo de validez es el titular, pero el mismo calendario movió los datos de validación que hay debajo, y los propios métodos de validación, lo que cambia lo que puede hacer un flujo de emisión automatizado.
| Requisito | Entrada en vigor | Dónde está escrito |
|---|---|---|
| Reutilización de los datos de validación de nombres de dominio y direcciones IP: 200 días | 2026-03-15 | Requisitos Base §4.2.1 |
| Reutilización de los datos de validación de la información de identidad del sujeto: 398 días, reducido desde 825 | 2026-03-15 | Requisitos Base §4.2.1 |
| La validación DNSSEC debe realizarse en todas las consultas DNS usadas para la validación de dominios y las búsquedas de CAA | 2026-03-15 | Requisitos Base §3.2.2.4 y §4.2.2.2 |
| La validación de dominios por correo electrónico y por teléfono ya no debería usarse para emitir certificados de suscriptor | 2026-03-15 | Requisitos Base §3.2.2.4 |
| Todo uso restante de SHA-1 en certificados y CRL llega a su fin | 2026-09-15 | Requisitos Base §7.1.3.2.1 |
Parámetros de CAA accounturi y validationmethods procesados según el RFC 8657 |
2027-03-15 | Requisitos Base §4.2.2.1.2 |
| Reutilización de los datos de validación de dominios y direcciones IP: 100 días, y luego 10 días | 2027-03-15, 2029-03-15 | Requisitos Base §4.2.1 |
La lectura práctica es que el número de días durante los que una validación sigue siendo reutilizable se encoge más rápido que la vida del certificado, y los métodos manuales que solían rescatar una renovación atascada —un correo a un buzón del dominio, una llamada telefónica— se están retirando del camino automatizado. Un flujo de emisión que depende de que un humano responda un mensaje es ahora un flujo que vulnera la intención del reglamento incluso antes de convertirse en un flujo que se rompe.
Primero el inventario, porque no puedes automatizar lo que no has nombrado
El incidente de certificado más común en una plataforma de tamaño medio no es un fallo criptográfico. Es un certificado que nadie recordaba: un comodín comprado por un equipo anterior para una integración que aún lo invoca, un certificado en la consola de un dispositivo, un certificado dentro de un dominio específico de un inquilino que introdujo un socio, un certificado en el backend móvil que nunca aparece en la lista de la infraestructura web.
El primer entregable es por tanto un registro, y tiene que responder preguntas en lugar de limitarse a contar filas:
| Columna | Por qué se necesita |
|---|---|
| Identificador de certificado y clave | La huella y el número de serie que resuelven un ticket de soporte hasta un objeto concreto |
| Sujeto y nombres alternativos del sujeto | Qué nombres de host cubre realmente la afirmación, incluidos los que nadie usa todavía |
| Emisor y cuenta de la CA emisora | Qué autoridad puede renovarlo, bajo qué cuenta, a través de qué API |
| Consumidor | Cada servicio, balanceador, dispositivo, compilación móvil y endpoint de socio que se romperá al caducar |
| Responsable | Un equipo, no un buzón de grupo |
| Ruta de automatización | El trabajo, el repositorio y el almacén de secretos exactos que realizan la renovación |
| Estado de renovación y fecha de la última renovación | Si la automatización se ha ejecutado alguna vez realmente en producción |
| Custodia de la clave | Si la clave privada se genera dentro de un módulo hardware y nunca sale de él, o existe como archivo |
Dos de esas columnas son las que las organizaciones dejan vacías de forma habitual, y son las dos que deciden cuán mala será la próxima caducidad: la lista de consumidores, porque es lo que convierte un certificado caducado en una caída cuyo alcance nadie puede predecir en los primeros diez minutos; y la ruta de automatización, porque una renovación automatizada que nunca se ha puesto a prueba es una suposición. Que la clave privada salga o no de un módulo hardware es una decisión de diseño y no una regla universal; lo que no es defendible es no saber la respuesta por certificado cuando un revisor la pide. La guía de aislamiento multiinquilino cubre la cuestión relacionada de quién posee un nombre de host dentro de una plataforma compartida, y la guía de migración y cambio cubre por qué un dominio que se mueve entre operadores debe rastrearse en lugar de darse por hecho.
Automatizar la emisión y demostrar que la automatización funciona
ACME, especificado en el RFC 8555, es la forma habitual de hacerlo. Su resumen lo describe sin rodeos: un protocolo que una autoridad de certificación y un solicitante «pueden usar para automatizar el proceso de verificación y emisión de certificados», con facilidades para otras funciones de gestión de certificados, incluida la revocación. El protocolo es solo la mitad de la automatización; la otra mitad es la fontanería que lo rodea: la credencial que usa el cliente, el desafío DNS o HTTP que debe superar, la recarga que entrega el certificado nuevo al servicio y la alerta que se dispara cuando cualquiera de esos pasos deja de ocurrir.
Cuatro propiedades separan una renovación automatizada de un script que da la casualidad de que se ejecuta:
- La renovación la guía el certificado, no un calendario. Preguntar al certificado desplegado cuándo caduca y renovar dentro de una ventana declarada sobrevive a un certificado que se emitió a mano, a un dominio que se añadió tarde y a un trabajo que se omitió una vez.
- La identidad del solicitante está restringida en DNS. Un registro CAA, definido por el RFC 8659, permite al titular de un dominio «especificar una o más Autoridades de Certificación (CA) autorizadas a emitir certificados para ese nombre de dominio», lo que es un control contra la emisión indebida por parte de una autoridad que nunca pretendías usar. El RFC 8657 lo amplía con dos parámetros que fijan la cuenta que puede solicitar la emisión y los métodos de validación que pueden usarse para ella, y los Requisitos Base ponen en vigor el segundo en 2027. Especificar tu propia cuenta ACME en un registro CAA es uno de los pocos controles que hacen menos útil una credencial comprometida en otro lugar.
- La recarga forma parte de la prueba. Un certificado renovado que el servicio no recoge hasta el siguiente despliegue es una caída programada con un paso de más. Sea cual sea el mecanismo —un hook de recarga, un sidecar, un proxy que lee el archivo en cada handshake—, la prueba de aceptación es que un certificado sustituido se sirve de inmediato, y su sitio está en el entorno de no producción, donde la ruta de renovación puede ejecutarse y fallar a propósito.
- La caducidad se monitoriza desde fuera de la plataforma. La monitorización interna comparte destino con el sistema que vigila. Una comprobación hecha desde una red separada, contra la dirección a la que los jugadores llegan realmente, y con alertas en un umbral expresado en días y no en horas, es la única comprobación que detecta una cadena de renovación rota antes que los jugadores. Con una cadencia de 200 días una revisión anual todavía sirve; con 47 no, y el umbral de alerta tiene que fijarse desde la ventana de renovación y no desde la costumbre.
Nombrar al suscriptor, no solo al host
Los certificados cumplen dos funciones en una plataforma de juego, y a menudo se confunden. Una es presentar el propio servicio del operador ante el navegador de un jugador. La otra es identificar un servicio ante otro servicio: la plataforma ante el proveedor de pagos, la plataforma ante el RGS, el back office ante una API interna, un microservicio ante otro.
La segunda función es donde falla el hábito centrado en el nombre de host. El RFC 9525, que deja obsoleto el RFC 6125, especifica «procedimientos para representar y verificar la identidad de servicios de aplicación» en TLS, y su argumento es que la identidad que se verifica es el servicio al otro lado de la conexión, no una máquina ni una dirección IP. En una plataforma ensamblada a partir de servicios y proveedores, esa distinción es la diferencia entre una API interna que autentica a quien llama y una API interna que solo cifra la conexión mientras confía en todo lo que está dentro del perímetro.
Para las integraciones con proveedores, el registro y el almacén de confianza tienen que moverse juntos. Cuando un socio rota su certificado, el cambio suele anunciarse por un canal de soporte y no por tu DNS, y una plataforma que fija el certificado del socio en un archivo de configuración sin un responsable y una fecha de revisión descubrirá la rotación en el momento en que la integración deja de liquidar. El pinning entre partes que controlan ambas el canal es razonable; el pinning entre partes que no lo hacen es una dependencia de una notificación que puede que no recibas.
Las aplicaciones móviles añaden su propia versión de este problema, porque una aplicación ya instalada en un dispositivo lleva consigo la decisión de confianza con la que se publicó. La guía de integridad de aplicaciones cubre la cuestión más amplia de qué puede demostrar un cliente sobre sí mismo; la regla específica de certificados es más estrecha y merece enunciarse sola: toda decisión de confianza incrustada en una compilación publicada tiene que comprobarse contra la cadencia de publicación de esa compilación, porque un certificado que cambia cada 47 días no puede ser un ancla de confianza permanente en una aplicación que se actualiza dos veces al año.
Mantener la clave privada donde corresponde
Un certificado es público. La clave privada no lo es, y el ciclo de vida de la clave es independiente del del certificado: un par de claves tiene un periodo de uso y un criptoperiodo, y la fecha de caducidad del certificado es solo uno de los eventos que los terminan.
La guía de gestión de claves del NIST es la referencia general aquí: SP 800-57 Parte 1 Revisión 5 ofrece «orientación general y buenas prácticas para la gestión de material de clave criptográfica», incluidos los servicios de seguridad que puede proporcionar la criptografía y la protección que se espera de cada tipo de clave, y trata los metadatos que rodean a las claves —quién es su dueño, de dónde vienen, cuándo pueden usarse— como parte del material que hay que proteger. Para el módulo que guarda las claves, FIPS 140-3, «Security Requirements for Cryptographic Modules», es el estándar contra el que se prueba un módulo de seguridad hardware validado. Para la configuración del protocolo por encima de eso, SP 800-52 Revisión 2 ofrece «orientación para la selección y configuración de implementaciones del protocolo TLS, aprovechando de forma efectiva los Estándares de Procesamiento de Información Federal (FIPS) y los algoritmos criptográficos recomendados por el NIST».
Ninguno de esos documentos certifica una plataforma de juego, y ninguno sustituye el criterio del propio operador sobre qué integraciones justifican un módulo hardware. Lo que establecen es una estructura: generar la clave donde va a vivir, mantenerla allí, darle un periodo de uso declarado y registrar quién puede usarla y para qué. Las preguntas que hace un revisor son correspondientemente específicas: dónde se generó esta clave, si ha salido alguna vez del módulo, quién puede solicitar una firma con ella, cuándo deja de ser válida y qué ocurre con los datos cifrados bajo ella cuando se retira. Una plataforma que pueda responder eso por certificado ha terminado con la parte más difícil de este trabajo, porque el resto del ciclo de vida es planificación.
Detectar emisiones que no solicitaste
Monitorizar la caducidad protege la disponibilidad. No protege contra el otro fallo: un certificado emitido para tu dominio por una autoridad que no elegiste, en un momento que no conocías.
Certificate Transparency existe precisamente para eso. El RFC 9162 describe un protocolo para «registrar públicamente la existencia de certificados de servidor TLS a medida que se emiten u observan, de forma que cualquiera pueda auditar la actividad de una autoridad de certificación (CA) y advertir la emisión de certificados sospechosos». Las autoridades públicas están obligadas a enviar los certificados a los registros, lo que convierte un registro público en una superficie de monitorización: una consulta sobre tus propios dominios, ejecutada de forma continua y contra una lista que mantienes, produce una alerta cuando se emite algo que tu inventario no explica.
Ese monitor pertenece a la misma revisión que el registro, y debería poder responder a la pregunta que un revisor de seguridad hará tras un titular sobre una emisión indebida: lo habríamos sabido, con qué rapidez y desde qué fuente. La guía de registro de seguridad y evidencia de auditoría cubre la disciplina general de evidencia; la versión específica de certificados es que el registro de la alerta, la entrada del registro y el ticket que lo cerró son los artefactos, no el panel.
La revocación es un runbook, no un endpoint de estado
Revocar un certificado es una decisión con un procedimiento asociado, y lo que falla bajo presión es el procedimiento. El protocolo de estado es solo el anuncio: el RFC 6960 especifica el Protocolo de Estado de Certificados en Línea (OCSP) como una forma de «determinar el estado actual de un certificado digital sin requerir Listas de Revocación de Certificados (CRL)». Si tus partes confiantes lo consultan de verdad es una pregunta aparte, y la balota que acortó los periodos de validez dice por qué ahora importa menos: sostiene que los servicios de estado de certificados «no protegen adecuadamente a las partes confiantes en la escala actual de internet», citando privacidad, rendimiento, puntualidad y exactitud, y trata una vida corta como la protección que no depende de que cada parte haga lo correcto a tiempo. Los certificados de vida corta no eliminan la necesidad de revocar; reducen la ventana en la que una revocación tiene que ser creída.
De ahí se derivan dos piezas de ingeniería. Primero, el stapling: el RFC 7633 define la extensión de característica de TLS, cuyo propósito es prevenir ataques de degradación y que «puede usarse para exigir el soporte de características de comprobación de revocación en el protocolo TLS, como el stapling de OCSP». Un certificado marcado con esa extensión convierte un staple ausente en un fallo duro en lugar de una omisión silenciosa, lo que es una cesión deliberada de disponibilidad y debería registrarse como tal.
Segundo, el propio runbook. El compromiso de un certificado es un incidente de seguridad con una secuencia de apertura fija: identificar cada servicio que usa la clave, revocar a través de la autoridad emisora, reemitir con un par de claves nuevo en lugar del mismo, confirmar qué protegía el certificado antiguo y decidir qué hay que tratar como expuesto. El plan de respuesta a incidentes es donde corresponde esa secuencia, y la razón para escribirlo mientras no hay nada mal es que la primera decisión en un evento real suele ser la que nadie puede tomar con rapidez: ¿es un compromiso de clave, una emisión indebida o un error de configuración, y quién lo declara?
Qué le hace un mundo de 47 días al resto de la pila
Acortar la vida útil no cambia la criptografía. Cambia el coste de cada operación que toca un certificado, y las operaciones que ignoran esto son las que producirán la caída.
- Alertas calibradas a una vida útil, no a un año. Una ventana de renovación, un umbral de aviso y un umbral crítico expresados como fracciones del periodo de validez real sobreviven a los pasos de 2027 y 2029 sin reescribirse. Valores fijos como «30 días» no lo hacen: son el 15 por ciento de un certificado de 200 días y el 64 por ciento de uno de 47.
- Gestión de cambios capaz de soportar un cambio semanal. Si sustituir un certificado es un ticket de cambio que exige una ventana de mantenimiento, con 47 días la plataforma tiene unas siete ventanas por certificado y año. La automatización en la que se confía sin ventana es la única versión que escala, y la confianza tiene que ganarse con evidencia: un ensayo en un entorno de no producción, una ruta de reversión y un historial de renovaciones que ya ocurrieron sin supervisión.
- Una ruta de recarga que no reinicie el mundo. La forma más común de que una renovación rutinaria se convierta en incidente es que aplicarla exija reiniciar un proceso que drena sesiones o reinicia un pool de conexiones compartido. Con una vida útil larga ese coste es raro; con una corta es recurrente, y la solución es arquitectónica y no procedimental.
- Claves rotadas junto con el certificado. Una renovación que reutiliza el par de claves existente es más barata y mantiene la clave antigua en servicio otro periodo. Reemitir con un par de claves nuevo es la práctica que hace que un compromiso sea retrospectivo y no indefinido, y merece decidirse de forma deliberada y no por defecto.
- Una lista de proveedores con fechas. Cualquier interfaz en la que la otra parte controla un certificado —pagos, identidad, contenido de juego, el endpoint de reporte de un regulador— es una dependencia con su propia fecha de caducidad. El registro debería incluir también esos certificados, marcados como ajenos, con la vía de contacto anotada.
Convertirlo en evidencia de aceptación
El paquete que un operador, un comprador o un auditor debería poder leer es corto, y cada elemento es comprobable en lugar de afirmado:
- El registro de certificados descrito antes, con un responsable nombrado y una lista de consumidores por entrada.
- El calendario público contra el que se gestiona cada certificado público, con las fechas que aplican hoy y el siguiente paso ya planificado.
- Para cada renovación automatizada: la cuenta o credencial usada, el método de desafío, el control de DNS que restringe la emisión y la fecha en que la ruta se puso a prueba por última vez en un entorno de no producción.
- El mecanismo de recarga, y la evidencia de que el servicio en ejecución sirve un certificado sustituido sin un paso manual.
- El monitor externo de caducidad, sus puntos de observación, sus umbrales y la ruta que siguen sus alertas.
- El monitor de transparencia de certificados para los dominios que posees, y la revisión que cierra una emisión no explicada.
- La declaración de custodia de claves: dónde se genera cada clave privada, si puede salir del módulo, su periodo de uso y quién puede usarla.
- El runbook de revocación, con la regla de reemitir con una clave nueva escrita dentro.
Nada de esto es un trabajo apasionante, y por eso se aplaza tantas veces hasta que una fecha de caducidad lo impone. El hábito de ingeniería al que pertenece —especificar el comportamiento antes de construirlo y mantener la especificación al día cuando las reglas cambian— es el mismo que hay detrás de la disciplina de desarrollo de plataforma que este sitio aplica en otros lugares. Para los certificados, las reglas cambiaron en marzo y volverán a cambiar en 2027 y 2029. Una plataforma que ya ha construido el registro, la automatización y el monitor leerá esas fechas como un dato de planificación. Una que no lo ha hecho las leerá como tres incidentes distintos con una causa común.
Preguntas que hace un equipo de plataforma
¿El límite de 200 días se aplica a nuestros certificados internos?
No con estos requisitos. Los Requisitos Base rigen los certificados destinados a autenticar servidores accesibles a través de internet, y un certificado emitido por tu propia autoridad interna para un servicio que no es accesible públicamente queda fuera de ese alcance. Eso es una declaración de alcance y no una promesa de seguridad: un certificado interno con dos años de vida y sin automatización sigue siendo una caducidad esperando a ocurrir, y la pregunta útil es si el entorno interno tiene un responsable, un registro y una ruta de renovación propios, y no si está cubierto legalmente.
Hoy renovamos anualmente. ¿Qué se rompe primero en realidad?
El orden de renovación, no la criptografía. Un ciclo anual es una renovación por certificado y año con un mes de aviso; a 200 días son aproximadamente dos, y a 47 días son aproximadamente ocho. Lo primero que falla son las cosas que daban por hecha la cadencia antigua: un recordatorio enviado a una sola persona, una ventana de cambio reservada por trimestres, un umbral de alerta fijado en días que ya no deja tiempo suficiente para actuar, y un paso de recarga manual que todos toleraban porque ocurría una vez al año.
¿Los certificados de vida corta significan que podemos ignorar la revocación?
No. Vidas más cortas reducen el tiempo que tiene una decisión de revocación para propagarse de forma fiable y reducen cuánto del ecosistema depende de que los servicios de estado se comporten, que es parte de por qué se adoptó el cambio. No sustituyen la revocación en los casos que más importan: una clave privada comprometida sigue teniendo que revocarse a través de su autoridad, porque hasta que el certificado caduque, cualquiera que tenga la clave puede presentarlo. La diferencia práctica es que la revocación pasa a ser un procedimiento raro, impulsado por incidentes y con un runbook, en lugar de una operación rutinaria, así que merece un ensayo y no un script que nadie ha ejecutado.
¿Es un certificado comodín una forma de reducir el número de renovaciones?
Reduce el número de certificados y aumenta el valor de cada uno. Una fecha de caducidad que sustituye a veinte es una simplificación operativa genuina, y también significa que una clave filtrada o una renovación omitida afectan a todos los nombres de host que cubre el comodín. La entrada del registro tiene que recoger ese alcance de impacto con honestidad, la lista de consumidores pasa a ser el conjunto completo de servicios cubiertos, y el comodín no debería ser la respuesta para un nombre de host que tiene otro responsable, otra exposición u otro requisito de disponibilidad.
¿Qué es lo más pequeño que construir primero si no tenemos nada?
El registro, con la columna de consumidores rellena. Cuesta unos días, no necesita ningún componente nuevo de plataforma y responde de inmediato a las dos preguntas que deciden cuán mala será la próxima caducidad: qué servicios se rompen y quién es responsable de cada certificado. La automatización sin esa lista renueva los certificados que recordabas, que es precisamente el conjunto que nunca iba a causar el incidente.
