La vigencia de los certificados TLS se reduce: qué significan 64 días y 45 días para dominios personalizados en túneles

El 10 de febrero de 2027, aproximadamente tres meses a partir de ahora, Let’s Encrypt cambia la vigencia predeterminada de los certificados de 90 días a 64 días. Unas cinco semanas después, el 15 de marzo de 2027, el máximo mundial para certificados TLS de confianza pública pasa de 200 días a 100. Ningún cambio es una sorpresa, y sin embargo pocos desarrolladores se han preguntado qué efecto tiene para un dominio personalizado apuntando a un túnel.

Si ejecutas app.yourdomain.com a través de un servicio de túneles, un certificado se sitúa entre tus usuarios (o tus emisores de webhook) y tu localhost. Alguien debe renovarlo cada vez que se acabe el tiempo, y ese tiempo va a avanzar más rápido. Esta guía cubre la cronología exacta, cómo funcionan la renovación y la verificación DNS detrás de un túnel, la diferencia entre certificados gestionados por el proveedor y BYO (bring-your-own), y los modos de fallo que aparecen cuando la renovación se detiene en silencio.

La Línea de Tiempo: qué está cambiando realmente y cuándo

Hay dos cronogramas distintos en juego, y la gente a menudo los confunde.

1. El calendario del CA/Browser Forum (aplica a cada CA pública)

En abril de 2025 el CA/Browser Forum aprobó Ballot SC-081v3. Disminuye tanto la validez máxima de certificados como el periodo en el que una CA puede reutilizar una validación de dominio previa (DCV). La votación se aprobó el 11 de abril de 2025, sin votos en contra.

Fecha efectiva	Validez máxima del certificado	Reutilización máxima de DCV
Hasta el 14 de marzo de 2026	398 días	398 días
15 de marzo de 2026 (ya vigente)	200 días	200 días
15 de marzo de 2027	100 días	100 días
15 de marzo de 2029	47 días	10 días

2. El calendario de Let’s Encrypt (la CA que la mayoría de túneles y configuraciones ACME usan)

Let’s Encrypt avanza más rápido que el mandato. Alcanzará 45 días en 2028, un año antes del máximo de 47 días del Forum.

Fecha	Perfil ACME	Validez	Reutilización de autorización
13 de mayo de 2026 (en vivo)	tlsserver (opción)	45 días	No especificado en el anuncio
10 de febrero de 2027	classic (predeterminado)	64 días	10 días (bajando desde 30)
16 de febrero de 2028	classic (predeterminado)	45 días	7 horas

Algunos detalles de los anuncios de Let’s Encrypt:

• El entorno de pruebas ya está en vivo. Los certificados de 64 días han estado disponibles en el entorno de staging de Let’s Encrypt desde el 14 de octubre de 2026, por lo que puedes probar tu configuración de renovación antes de que entren cambios en producción.
• Los certificados existentes no se revocan. Let’s Encrypt espera que el último certificado de 90 días expire el 11 de mayo de 2027.
• Los usuarios de los perfiles tlsserver (45 días) o shortlived (6 días) no se ven afectados por el cambio de febrero.
• El periodo corto de reutilización de autorización es la parte tranquila. A medida que la ventana de reutilización se reduce, demuestras el control del dominio en prácticamente cada emisión en lugar de apoyarte en una validación en caché. Let’s Encrypt afirma que esto también elimina la necesidad de la “rea comprobación de CAA” cuando los datos de validación tienen más de siete horas de antigüedad.

Si usas el perfil predeterminado y nunca modificaste la configuración de tu cliente ACME, el cambio de febrero de 2027 te llega automáticamente. Eso está bien si tu renovación está realmente automatizada. Es un problema si “automatizado” significa un cron job que nadie ha mirado desde 2023.

Por qué los Dominios Personalizados en Túneles son un Caso Especial

En un servidor normal posees la clave privada y ejecutas el cliente ACME tú mismo. Con un túnel, el borde público pertenece al proveedor, y tu dominio es un alias que apunta a él. Eso reparte la responsabilidad en tres:

• El proveedor termina TLS y (por lo general) obtiene y renueva el certificado.
• Tú controlas los registros DNS que hacen posible la emisión.
• Tu aplicación local nunca ve el certificado.

Las duraciones más cortas ejercen mayor presión sobre la mitad DNS de ese acuerdo. El trabajo de renovación del lado del proveedor puede ser impecable y aun así fallar porque un registro en tu lado se desvió.

Certificados Gestionados por el Proveedor: Convenientes, No Invisibles

La mayoría de plataformas de túneles por defecto utilizan certificados gestionados, y la documentación de ngrok es un ejemplo concreto. Recomiendan certificados automáticos a menos que tengas requisitos especiales. Para estos, proveen y renuevan certificados de una CA compatible con ACME como Let’s Encrypt. Usan un reto HTTP-01 para la mayoría de dominios y cambian a DNS-01 para dominios wildcard.

Para un dominio con marca como api.your-domain.com, creas un registro CNAME, y la provisión no comienza hasta que lo haces. Para un wildcard como *.app.example.com, necesitas dos CNAMEs: el propio wildcard y _acme-challenge.app.example.com.

La provisión es asíncrona. ngrok indica que normalmente toma desde unos segundos hasta varios minutos, y ocasionalmente más tiempo si un desafío DNS tarda en validar. Mientras se ejecuta, ngrok sirve su propio certificado wildcard predeterminado. Ese certificado no está emitido para tu nombre de host, por lo que los navegadores y otros clientes TLS muestran una advertencia de desajuste de nombre de host.

Esa documentación describe a un vendedor, pero el patrón es común. Te dice qué observar ante duraciones más cortas:

1. El CNAME es tu credencial de emisión. Si alguien “limpia” DNS y lo elimina, la provisión no puede continuar. A 398 días puede que no lo notes durante un año. A 64 días te enteras en aproximadamente dos meses, y a 45 días en aproximadamente seis semanas.
2. Los comodines dependen de un segundo registro. El CNAME _acme-challenge es fácil de olvidar, porque nada parece romperse hasta que el certificado necesita renovarse.
3. Los certificados de respaldo parecen una interrupción. Una advertencia de desajuste de nombre de host es una falla severa para muchos clientes API y emisores de webhook, incluso si un humano podría hacer clic para continuar.

Los certificados gestionados no eliminan tus obligaciones. Las reducen a una lista corta: mantener los registros DNS correctos y vigilar el resultado.

Certificados BYO (Trae Tus Propios Certificados): Control con una Cuota de Rotación

Algunos equipos suben su propio certificado: uno de una CA interna, un certificado EV, o uno fijado por un socio. Eso es legítimo, y la compensación se agudiza a medida que los periodos de vida se reducen.

Con ngrok, por ejemplo, certificados personalizados significan que eres responsable de la renovación y la rotación. Subes un paquete PEM con el certificado hoja primero, seguido de cualquier intermedio, además de una clave privada que no esté encriptada. Luego adjuntas el certificado a uno o más dominios, porque crearlo solo no genera tráfico.

En ngrok, los certificados TLS están disponibles en todos los planes, pero los certificados BYO requieren el plan de pago por uso. Se facturan a una tarifa plana de $0.27 por hora por cualquier hora en la que al menos un extremo usando ese certificado esté activo. Un certificado comodín se factura una sola vez, no por subdominio coincidente. Los precios y reglas de planes difieren entre proveedores, así que consulta el tuyo.

Ahora haz las cuentas de rotación para un solo nombre de host:

Vida útil máxima	Rotaciones mínimas por año
398 días	1
200 días	2
100 días	4
64 días	6
47 días	8

Estas son los mínimo si reemplazas cada certificado exactamente al vencimiento. Renovarlo antes, como deberías, eleva el número real.

Un proceso manual que antes se toleraba una vez al año (descargar, convertir, subir, adjuntar, probar) se convierte en un costo operacional recurrente de seis a ocho veces al año por nombre de host, multiplicado por cada entorno. Si debes usar BYO, automatiza todo el camino:

1. Tu cliente ACME obtiene el certificado.
2. Un hook de despliegue lo sube a través de la API del proveedor.
3. Un segundo paso lo adjunta al dominio.
4. Una verificación comprueba la caducidad del certificado activo después.

Considera cualquier paso que no puedas automatizar como el que hará fallar.

El calendario del Foro se aplica a certificados con confianza pública. Un certificado de una CA privada en la que tus clientes confían queda fuera, pero no ayuda cuando servicios externos llaman a la URL de tu túnel.

Qué se rompe cuando la renovación falla en silencio

“Silenciosamente” es la palabra clave. Varias cosas que antes amortiguaban fallos son más débiles ahora:

• Ya no hay correos de recordatorio. Let’s Encrypt terminó sus correos de notificación de expiración el 4 de junio de 2025. Recomienda la monitorización de terceros, y su página de monitorización llama a Red Sift Certificates Lite, que es gratuita para hasta 250 certificados. Si dependías de ese correo como red de seguridad, ya no existe.
• Las ventanas más cortas dejan menos holgura. Let’s Encrypt recomienda renovar en aproximadamente dos tercios de la vida útil de un certificado. Para un certificado de 45 días, eso significa renovar alrededor del día 30, dejando unos 15 días para corregir un fallo. Para un certificado de 64 días, alrededor del día 43, dejando unas tres semanas.
• La reutilización está disminuyendo. Con la reutilización de autorizaciones cayendo a 10 días y luego 7 horas para el perfil predeterminado de Let’s Encrypt, “funcionó la última vez” ya no implica “funcionará esta vez.”

Modos de fallo típicos en dominios personalizados de túneles:

Fallo	Síntoma probable
CNAME eliminado o redirigido durante una migración DNS	La provisión o renovación no puede continuar; el estado del proveedor muestra un error
Solicitud HTTP-01 bloqueada por un firewall, WAF o política de acceso	Error de emisión tras un cambio de configuración
Token de API DNS caducado o rotado (configuraciones DNS-01)	La automatización falla en los registros que nadie lee
Registro CAA que excluye la CA en uso	Emisión rechazada
Cliente ACME antiguo o cron job abandonado	No hay intentos de renovación
Certificado BYO cargado no reemplazado	El certificado caducado sigue siendo el adjunto al dominio

Dos detalles de la documentación de Let’s Encrypt son relevantes aquí. Primero, HTTP-01 solo puede hacerse en el puerto 80. Su validación puede seguir hasta 10 redirecciones, pero solo a los puertos 80 o 443. Segundo, Let’s Encrypt verifica los registros CAA antes de emitir, y su identificador CAA es letsencrypt.org.

Los proveedores de Webhook y los consumidores de API son los menos indulgentes. Una persona podría hacer clic para pasar la advertencia, pero un emisor automatizado normalmente simplemente falla el apretón TLS, y la primera señal son eventos ausentes en lugar de una página de error visible.

Calendario de Renovación: Deja de Usar Desplazamientos Fijos

Muchas herramientas estaban configuradas para certificados de 90 días con una regla fija, como “renovar cuando falten 30 días” o “renovar cada 60 días.” La propia guía de Let’s Encrypt es contundente. Un intervalo codificado de 60 días ya no es suficiente para certificados de 45 días. Recomienda buscar en trabajos de cron, scripts envoltorios y runbooks números codificados como 83, 80 o 60. Cualquier cosa que espere 80 días perderá completamente un certificado de 64 días.

La mejor respuesta es ACME Renewal Information (ARI), estandarizado como RFC 9773. La CA indica al cliente cuándo renovar, y los clientes deben renovar dentro de la ventana sugerida. Let’s Encrypt recomienda ARI, y dice que si tu cliente no lo tiene, renovar en aproximadamente dos tercios de la vida útil del certificado es aceptable.

Certbot ha verificado ARI automáticamente cuando la CA lo admite desde la versión 4.1.0 (junio de 2025). Otros clientes difieren, así que verifica tu cliente y versión específicos en lugar de asumir. Para los proveedores de túneles, pregunta si su canal de renovación usa timing basado en ARI, ya que tú no lo controlas.

Verificación DNS Bajo Vidas Más Cortas

HTTP-01 vs DNS-01

HTTP-01 es simple para nombres de host únicos: la CA obtiene un token de tu sitio. En un túnel, el proveedor usualmente lo responde por ti una vez que el CNAME está en su lugar. DNS-01 es obligatorio para comodines y funciona donde HTTP-01 no puede, pero necesita acceso de escritura DNS en cada emisión. Let’s Encrypt señala que colocar credenciales completas de la API DNS en un servidor web aumenta el impacto de una posible brecha. Recomienda credenciales con alcance limitado, o validar desde un servidor separado.

Delegar el desafío en lugar de compartir claves DNS

Let’s Encrypt sigue búsquedas DNS estándar para la validación DNS-01, así que puedes usar registros CNAME o NS para delegar el nombre _acme-challenge a otra zona. Eso te permite apuntar _acme-challenge.yourdomain.com a una zona reservada para automatización, con credenciales limitadas a esa zona solamente. El soporte de cliente para seguir la delegación varía, así que confirma el tuyo y prueba con una simulación antes de confiar en ello.

DNS-PERSIST-01: una nueva opción para vigilar

Let’s Encrypt ha descrito un nuevo tipo de desafío, DNS-PERSIST-01, basado en un borrador IETF. En lugar de publicar un token nuevo en cada emisión, publicas un registro TXT permanente en _validation-persist.<domain> que nombra a la CA y tu cuenta ACME específica. Las renovaciones no requieren cambios DNS, por lo que el acceso de escritura DNS se puede bloquear tras la configuración.

El alcance y la vida útil se controlan con parámetros opcionales. policy=wildcard amplía la autorización a certificados wildcard y subdominios coincidentes. persistUntil establece una marca de tiempo de expiración. Sin una expiración, la autorización dura indefinidamente, así que establece un recordatorio de monitoreo. Debido a que el registro persiste, proteger la clave de tu cuenta ACME se convierte en la preocupación central. El CA/Browser Forum aprobó el método de validación subyacente en el ballot SC-088v3 en octubre de 2025.

Let’s Encrypt tenía previsto un lanzamiento de producción en el segundo trimestre de 2026, empezando por staging. No pude encontrar confirmación de que esté en producción. La discusión comunitaria a finales de julio de 2026 describió el borrador IETF como aún ajustándose y dijo que ninguna CA pública tenía una implementación de producción. Trátalo como algo para planificar, no para depender de ello. También importa si tu proveedor de túneles lo soporta, no solo tu propio cliente ACME, porque en un dominio gestionado el proveedor mantiene la cuenta ACME.

Una Lista de Verificación Práctica para Dominios Personalizados en Túneles

Antes del 10 de febrero de 2027

1. Inventario de cada hostname personalizado y anota quién lo renueva: el proveedor, tu cliente ACME, o una persona.
2. Verifica los registros DNS (el objetivo CNAME, más _acme-challenge para comodines) frente a las instrucciones actuales de tu proveedor.
3. Verifica los registros CAA para confirmar que permiten a la CA emitir realmente.
4. Prueba la renovación de extremo a extremo. Ejecuta tu cliente ACME contra Let’s Encrypt en staging, que ha emitido certificados de 64 días desde el 14 de octubre. Para dominios gestionados, confirma que el campo de estado o el tablero de tu proveedor muestra un certificado saludable.
5. Actualiza clientes antiguos. Asegúrate de que el tuyo soporte perfiles ACME y ARI, y elimina desplazamientos de renovación codificados.

En curso

1. Monitorea el certificado en vivo, no el trabajo. Realiza una verificación externa que se conecte a cada hostname y alerte cuando la vida restante caiga por debajo de un umbral, como el último tercio de la vida del certificado. Un job que sale con código 0 no demuestra nada sobre lo que está sirviendo el edge.
2. Alerta ante deriva DNS. Una verificación programada que tus CNAMEs sigan resolviendo a los objetivos esperados detecta la falla más común de certificados gestionados.
3. Documenta la propiedad. Cuando la persona que configuró el dominio se vaya, el proceso de renovación no debería irse con ellos.
4. Ensaya la falla. Conoce los pasos de recuperación manual (recrear el registro, activar la reemisión, volver a subir) antes de necesitarlos a las 2 a.m.

¿Gestión por el Proveedor o BYO? Una Guía Rápida de Decisiones

Situación	Mejor opción
Sitio público estándar, webhooks, API en un dominio personalizado	Gestionado por el proveedor
Equipo pequeño, sin operaciones dedicadas	Gestionado por el proveedor
Requisito contractual para una CA específica o tipo de certificado	BYO, con subida automatizada
Certificado fijado por un socio	BYO, con un runbook de rotación
Wildcard en muchos túneles	Gestionado con delegación DNS-01, o BYO con automatización

Para la mayoría de desarrolladores la ruta gestionada es la adecuada, y las duraciones más cortas fortalecen el caso. Un proveedor que renueva continuamente está haciendo el trabajo que, de otro modo, tendrías que automatizar.

Dónde encajan los Dominios Personalizados Pro

Los dominios personalizados son el punto en el que un túnel deja de ser una URL desechable y pasa a formar parte de tu infraestructura: un nombre de host estable para webhooks, demos, staging o una vista previa de un cliente. Eso convierte la gestión de certificados en parte de lo que estás comprando. Al evaluar un plan Pro de dominio personalizado de cualquier proveedor de túneles, pregunta:

• ¿Se emiten y renuevan automáticamente los certificados, y qué ocurre con el hostname si la renovación falla?
• ¿Qué tipos de desafío y registros DNS se requieren, y puedo ver el estado y la caducidad del certificado en un panel o API?
• ¿Está disponible el soporte de wildcard, y cómo se maneja el registro _acme-challenge?
• ¿Puedo traer mi propio certificado, y la rotación se puede automatizar a través de una API? ¿Cuánto cuesta?
• ¿Cómo te alerta el proveedor antes de la expiración, dado que los correos de recordatorio de Let’s Encrypt ya no existen?

Un plan que responda claramente a estas preguntas convierte los cambios de 64 días y 45 días en algo que no merece atención.

Preguntas Frecuentes

¿El cambio de 64 días es una regla del CA/Browser Forum?
No. El valor predeterminado de 64 días es un paso interino propio de Let’s Encrypt. El máximo actual del Foro es de 200 días, que caerá a 100 el 15 de marzo de 2027.

¿Necesito hacer algo si mi proveedor de túneles gestiona certificados?
Principalmente mantén intactos tus registros DNS y vigila el certificado que realmente sirve tu hostname.

¿Let’s Encrypt certificados serán de 47 días?
No. Let’s Encrypt planea 45 días a partir del 16 de febrero de 2028, ligeramente por debajo del máximo eventual de 47 días del Foro en 2029.

¿Qué pasa con mis certificados de 90 días existentes?
Seguirán siendo válidos hasta que expiren, y ninguno se revoca como parte del cambio. Let’s Encrypt espera que el último certificado de 90 días expire el 11 de mayo de 2027. Cualquier cosa emitida o renovada desde el 10 de febrero de 2027 obtiene 64 días.

¿Esto se aplica a certificados autofirmados o de CA privadas?
El calendario rige certificados TLS de confianza pública, por lo que PKI privado queda fuera, aunque los llamados externos no confiarán en tales certificados.

Conclusiones Clave

• Las fechas clave son 10 de febrero de 2027 (Let’s Encrypt pasa a 64 días), 15 de marzo de 2027 (límite de la industria de 100 días), 16 de febrero de 2028 (Let’s Encrypt pasa a 45 días) y 15 de marzo de 2029 (límite de 47 días, reutilización de DCV de 10 días).
• En túneles, el riesgo rara vez es el motor de renovación del proveedor. Es deriva DNS, credenciales expiradas, y certificados BYO que nadie rotó.
• Monitorea externamente el certificado servido, porque los correos de recordatorio de Let’s Encrypt terminaron en junio de 2025.
• Reemplaza desplazamientos de renovación codificados por ARI o renovación a aproximadamente dos tercios de la vida útil.
• Prefiere certificados gestionados a menos que exista una necesidad real que lo exija, y automatiza cada paso si traes los tuyos.

Fuentes

• CA/Browser Forum Ballot SC-081v3 schedule: SSLInsights, Odown, DNSimple
• Let’s Encrypt / ISRG: Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt community: DNS-PERSIST-01 deployment status and win-acme discussion
• Let’s Encrypt: Expiration Notification Service Has Ended
• Let’s Encrypt: Monitoring Service Options
• Let’s Encrypt: Challenge Types
• Let’s Encrypt: CAA
• ngrok: TLS certificates documentation
• Certbot 4.1.0 release (ARI support)
• IETF: ACME Renewal Information, RFC 9773