- Los plazos que impulsan el cambio
- Por qué los certificados más cortos dificultan la validación manual del dominio.
- ¿Qué es la validación de control de dominio (DCV)?
- ¿Qué es la DCV persistente (DNS-PERSIST-01)?
- DCV tradicional frente a DCV persistente
- ¿Qué son los conectores DNS?
- Cómo funcionan conjuntamente los conectores DCV y DNS persistentes
- Directrices: qué hacer antes de que se acerquen las fechas lÃmite.
- CertSecure Manager v3.3: Automatización DNS-01 independiente de CA
- Puntos clave
- Cómo puede ayudar Encryption Consulting
- Conclusión
- Lecturas relacionadas de Encryption Consulting
La validación de control de dominio (DCV) es el paso en el que una Autoridad de Certificación confirma que quien solicitó un certificado controla realmente el dominio al que está destinado. Para la mayorÃa de los equipos, esta era una tarea anual que se realizaba discretamente junto con la renovación. Sin embargo, esta suposición ya no es válida. El mandato del Foro CA/Browser ha establecido un calendario fijo que reduce la vigencia de los certificados de 398 dÃas en la actualidad a 47 dÃas para 2029, y también limita el tiempo durante el cual se puede reutilizar la evidencia de validación de dominio. Cuando un certificado debe reemitirse cada seis o siete semanas, la validación que lo respalda debe actualizarse constantemente.
Dos capacidades permiten que este ritmo sea sostenible: la validación persistente del dominio (método DNS-PERSIST-01), que permite verificar nuevamente un dominio con un único registro publicado una sola vez, y los conectores DNS, que automatizan los cambios DNS que aún requiere la validación. Este artÃculo explica qué es cada uno, los plazos exactos que obligan al cambio, los cálculos operativos que los sustentan y una guÃa práctica para prepararse.
Los plazos que impulsan el cambio
En abril de 2025, el Foro CA/Browser aprobó la propuesta SC-081v3 , titulada «Introducción de un calendario para la reducción de los periodos de validez y reutilización de datos», con 29 votos a favor y ninguno en contra. Esta propuesta, originalmente presentada por Apple, establece una reducción gradual tanto de la vida útil máxima de los certificados TLS de confianza pública como del periodo durante el cual se pueden reutilizar los datos de validación. Todos los certificados TLS de confianza pública se ven afectados, incluidos los certificados DV, OV y EV, asà como los certificados comodÃn y multidominio (SAN).
| Fecha efectiva | Validez máxima de TLS | perÃodo de reutilización de DCV | Reutilización de SII (OV/EV) |
|---|---|---|---|
| Hasta el 14 de marzo de 2026 | 398 dÃas | 398 dÃas | 825 dÃas |
| 15 de marzo de 2026 | 200 dÃas | 200 dÃas | 398 dÃas |
| 15 de marzo de 2027 | 100 dÃas | 100 dÃas | 398 dÃas |
| 15 de marzo de 2029 | 47 dÃas | 10 dÃas | 398 dÃas |
Los lÃmites de validez y reutilización de los certificados DCV se aplican en función de la fecha de emisión del certificado, no de la fecha en que se realiza el pedido.
El plazo para reutilizar la información de identidad del sujeto (SII) para los certificados OV y EV también se reduce de 825 a 398 dÃas el 15 de marzo de 2026. Este cambio pone fin al modelo de "configurar y olvidarse" para los certificados de alta seguridad. Para consultar el conjunto completo de mandatos relacionados, incluido el plazo independiente para la doble EKU de Chrome del 15 de junio de 2026, consulte nuestro análisis del mandato del CA/Browser Forum . Este mismo cambio también modifica cuándo confiar en una CA pública o privada.
Por qué los certificados más cortos dificultan la validación manual del dominio.
El problema no reside en el certificado en sÃ, sino en la frecuencia de su renovación. Consideremos una organización con 1,000 certificados de confianza pública. Actualmente, con una validez de 398 dÃas, este conjunto de certificados genera aproximadamente 1,000 renovaciones al año. Para 2029, con una validez de 47 dÃas, el mismo conjunto generará más de 8,000 renovaciones anuales, lo que representa un aumento de ocho veces en el mismo trabajo.
La validación se ve afectada de forma aún más directa. Cuando el perÃodo de reutilización de DCV se reduce a 10 dÃas, mientras que los certificados duran 47 dÃas, la propiedad del dominio debe verificarse aproximadamente 35 veces al año por dominio. La validación por correo electrónico y la colocación puntual de archivos HTTP no pueden funcionar con esa frecuencia. Los equipos más expuestos son aquellos que administran grandes conjuntos de datos, certificados SAN que agrupan muchos dominios bajo una sola validación y dominios comodÃn. La exposición es mayor cuando la propiedad del DNS está dividida entre los equipos de redes, infraestructura y plataforma, y ​​cuando cada cambio depende de un ticket de gestión de cambios.
La implicación es clara. Con frecuencias de renovación automatizadas, la gestión manual de certificados deja de ser viable, y la automatización de las operaciones de certificados se convierte en la norma. La pregunta es qué forma de automatización reduce al máximo el riesgo operativo.
¿Qué es la validación de control de dominio (DCV)?
La validación del control de dominio es el proceso que utiliza una CA para confirmar que el solicitante del certificado controla el dominio especificado en la solicitud. Los requisitos básicos del Foro CA/Navegador definen varios métodos aceptados. Los tres más utilizados son:
- La validación basada en DNS requiere que el solicitante publique un registro TXT bajo el dominio, que la CA verifica posteriormente. Este es el único método que admite dominios comodÃn y se adapta fácilmente a la automatización.
- La validación basada en HTTP requiere que el solicitante coloque un archivo en una ruta conocida del servidor web. Funciona para hosts individuales, pero se vuelve problemática en entornos distribuidos o con balanceo de carga.
- La validación por correo electrónico requiere que el solicitante responda a un mensaje enviado a un contacto del dominio. Este método está supervisado por personas y se está eliminando gradualmente para dar paso a la emisión automatizada.
Para las organizaciones que operan a gran escala, la validación basada en DNS es la opción más práctica. Funciona con comodines, se puede gestionar completamente mediante API y sirve de base para los protocolos de emisión automatizada que el nuevo cronograma prácticamente hace obligatorios, en particular ACME y su desafÃo DNS-01. Tanto la validación persistente de dominios (DCV) como los conectores DNS se basan directamente en esta infraestructura DNS.
¿Qué es la DCV persistente (DNS-PERSIST-01)?
La validación persistente de dominio (DCV) es un método de validación basado en DNS que elimina la necesidad de crear y eliminar un registro DNS para cada emisión. Se incorporó a los Requisitos Básicos como la sección 3.2.2.4.22, titulada "Registro DNS TXT con valor persistente" y conocida popularmente como DNS-PERSIST-01, mediante la votación SC-088v3 , y se convirtió en un método permitido en noviembre de 2025. Fue propuesta por Amazon Trust Services y respaldada por Google Chrome, DigiCert y Sectigo, entre otros.
El funcionamiento es sencillo. En lugar de crear un registro temporal nuevo para cada evento de validación, el propietario del dominio publica un único registro TXT con ámbito de cuenta una sola vez, con la etiqueta _validation-persist.[dominio]. Este registro identifica la cuenta de CA del solicitante. A partir de entonces, la CA realiza comprobaciones de validación recurrentes contra el mismo registro automáticamente, sin necesidad de realizar más cambios en el DNS. Es importante destacar que la DCV persistente no debilita la verificación de la propiedad del dominio. El Foro CA/Navegador exige que proporcione una seguridad equivalente a la de los métodos basados ​​en DNS existentes. Modifica cuándo y cómo se realiza la verificación, pasando de comprobaciones basadas en eventos a una revalidación continua y automatizada. Las CA siguen sujetas al mismo lÃmite de reutilización de 10 dÃas, y la DCV persistente implica que el registro subyacente nunca tiene que reconstruirse para cumplir con dicho lÃmite.
El registro en sà codifica quién está autorizado a emitir. Un registro TXT persistente tiene el siguiente formato:
_validation-persist.example.com IN TXT (
"authority.example;"
" accounturi=https://authority.example/acct/123;"
" persistUntil=1782424856"
)
El nombre del registro identifica el dominio; la autoridad identifica a la CA; accounturi identifica la cuenta ACME autorizada para emitir (según RFC 8657, y se mantiene estable entre rotaciones de claves conforme a la Sección 7.3.5 de RFC 8555); y la opción persistUntil establece una fecha de caducidad. La CA vuelve a comprobar este único registro en cada emisión.
El ahorro operativo es proporcional al tamaño de la infraestructura. Una organización que valida 100 dominios cuatro veces al año realiza aproximadamente 400 cambios de DNS anuales con el método DNS-01 convencional, en comparación con 100 registros únicos con la validación persistente de dominios (DCV).
Una disyuntiva merece especial atención. Dado que un registro permanente autoriza la emisión, el activo a proteger pasa del acceso de escritura DNS a la clave de la cuenta ACME. Considere esa clave como una credencial sensible, supervise el registro persistente para detectar cambios inesperados y tenga en cuenta que la emisión puede revocarse inmediatamente desactivando la cuenta ACME (RFC 8555, Sección 7.5.2).
DCV tradicional frente a DCV persistente
| DCV tradicional basado en DNS | DCV persistente (DNS-PERSIST-01) |
|---|---|
| Se crea un registro TXT temporal y único para cada evento de emisión. | Se publica un único registro TXT persistente una sola vez en _validation-persist. |
| El registro se agrega, se valida y luego se elimina o se rota en cada ciclo. | La CA vuelve a comprobar el mismo registro en cada emisión; no es necesario realizar ningún cambio en el DNS. |
| La coordinación del DNS se repite en cada renovación, que es el punto de fallo que aumenta con la frecuencia. | La coordinación DNS se realiza una sola vez durante la configuración; las renovaciones están desvinculadas del funcionamiento de DNS. |
| Su frecuencia aumenta ocho veces a medida que su validez se reduce a 47 dÃas. | La frecuencia de emisión ya no es el factor determinante de la carga de trabajo del DNS. |
¿Qué son los conectores DNS?
La validación persistente de certificados (DCV) reduce la frecuencia con la que se necesitan cambios en el DNS; los conectores DNS gestionan los cambios restantes. Un conector DNS es una integración entre una plataforma de gestión del ciclo de vida de los certificados y un proveedor de DNS que permite a la plataforma crear, actualizar y validar registros TXT mediante programación, a través de la API del proveedor, en lugar de requerir que un administrador de DNS realice cada cambio manualmente.
Esto es importante porque la parte más lenta de la validación basada en DNS no suele ser la consulta DNS, sino la transferencia manual. Un equipo de certificados solicita un registro, un equipo de redes programa el cambio, transcurre un plazo de aprobación y solo entonces se completa la validación. Con una cadencia anual, este retraso es tolerable. Sin embargo, con una cadencia de docenas de validaciones por dominio al año, se convierte en la principal fuente de retraso operativo y riesgo de interrupción, ya que una renovación puede fallar por completo si su registro de validación no está disponible a tiempo. Los conectores eliminan la transferencia manual: la plataforma se comunica directamente con el proveedor de DNS y el registro aparece, se valida y se gestiona sin necesidad de un ticket.
Cómo funcionan conjuntamente los conectores DCV y DNS persistentes
Ambas capacidades son complementarias, no intercambiables. La verificación persistente de dominio (DCV) elimina los puntos de contacto DNS durante el ciclo de renovación. Los conectores DNS automatizan los cambios DNS que aún son necesarios, incluyendo la publicación del registro persistente inicial y la incorporación de nuevos dominios. Utilizadas en conjunto, brindan a un equipo dos herramientas distintas:
- Cuando se puede utilizar un registro persistente, los cambios de DNS durante la renovación se eliminan por completo, por lo que la frecuencia de emisión ya no genera la carga de trabajo de DNS.
- Cuando aún se requiere un cambio de DNS (dominios nuevos, configuración inicial, proveedores sin soporte permanente), un conector lo ejecuta automáticamente, sin necesidad de coordinación manual.
El resultado final es un flujo de trabajo de validación que se adapta perfectamente al aumento tanto del volumen de certificados como de la frecuencia de renovación, que es precisamente lo que exigen los plazos de 2027 y 2029.
Directrices: qué hacer antes de que se acerquen las fechas lÃmite.
El plazo para prepararse está abierto, pero se está reduciendo, y el primer hito de validez de 200 dÃas ya está en vigor. Las organizaciones que realicen una transición sin problemas serán las que implementen la automatización ahora, no las que reaccionen cuando los certificados de 100 dÃas hagan insostenibles los flujos de trabajo manuales en 2027. Una secuencia práctica:
- Inventarie el conjunto de certificados. Descubra todos los certificados de confianza pública, prestando especial atención a aquellos que caduquen después del 15 de marzo de 2026. Las lagunas en el descubrimiento, es decir, los certificados que nadie recuerda, son la principal causa de interrupciones silenciosas.
- Revise los registros antiguos de DCV. Identifique los datos de validación que se acercan a su fecha de vencimiento para que las renovaciones no fallen por falta de evidencia actualizada.
- Priorice los dominios SAN y comodÃn. Estos conllevan la mayor sobrecarga de coordinación y la mayor sensibilidad en plazos ajustados.
- Adopte la validación continua de dominios (DCV) persistente para los dominios establecidos. Publique los registros persistentes ahora, antes de que la frecuencia de renovación obligue a realizar el cambio a gran escala.
- Automatice la ejecución de DNS con conectores. Conecte sus proveedores de DNS para que la configuración inicial y la incorporación de nuevos dominios nunca dependan de cambios manuales en los registros.
- Estandarizar la emisión automatizada. Tratar la emisión pública de TLS como un servicio continuo impulsado por ACME o un protocolo equivalente, y establecer una fecha lÃmite para eliminar las renovaciones manuales.
CertSecure Manager v3.3: Automatización DNS-01 independiente de CA
CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting, independiente del proveedor. Su diseño independiente de la CA implica que un único plano de control descubre, emite, renueva y gestiona los certificados en todas las autoridades que utiliza una organización, de modo que los cambios de validez y validación se gestionan de forma centralizada en lugar de autoridad por autoridad, y un certificado puede volver a emitirse desde una CA diferente si una falla.
Esta neutralidad cobra especial importancia en la capa de confianza pública, donde el plazo de 47 dÃas tiene el mayor impacto. CertSecure Manager se integra de forma nativa con los principales proveedores de confianza pública, como DigiCert , GlobalSign , Sectigo, Let's Encrypt y Google Public CA, además de autoridades privadas como Microsoft AD CS, AWS Private CA y HashiCorp Vault. Independientemente de la CA pública que emita un certificado, la detección, emisión, renovación y validación se gestionan desde la misma consola.
Para las organizaciones que buscan gestionar o automatizar la validación DNS-01 especÃficamente, CertSecure Manager v3.3 está diseñado precisamente para esta transición. Encryption Consulting está brindando apoyo activo a los equipos para:
- Integre sus proveedores de DNS públicos conectando los proveedores que alojan sus zonas DNS, de modo que los registros de desafÃo DNS-01 se creen y verifiquen automáticamente en una amplia gama de proveedores. Esto elimina la necesidad de transferir manualmente la información entre los equipos de certificados y DNS.
- Gestione la validación de dominios de control (DCV) mediante la automatización programada, ejecutando validaciones de dominio recurrentes alineadas con la cadencia de renovación que exigen los certificados de 100 y 47 dÃas, de modo que la evidencia DNS-01 se mantenga actualizada sin intervención en cada ciclo.
- Mantenga la validación independiente de la CA aplicando la misma automatización DNS-01 independientemente de qué CA pública emita el certificado, de modo que la consolidación o el cambio de proveedores no requiera reconstruir el flujo de trabajo de validación.
- Cree flujos de trabajo preparados para la automatización en toda la infraestructura mediante el descubrimiento continuo, la aplicación de polÃticas y los agentes de renovación sin intervención manual, de modo que las renovaciones a ritmo de máquina no se traduzcan en un esfuerzo manual proporcional.
Un vistazo a la sección DNS de CertSecure Manager muestra cómo funciona esto en la práctica:

Figura 1. Incorporación del proveedor DNS y configuración del conector DNS-01.

Figura 2. Validación del dominio DNS-01 con CertSecure Manager.
El objetivo es el modelo operativo que presupone el nuevo cronograma: la validación de dominios tratada como un sistema coordinado y automatizado, en lugar de una tarea puntual que se repite en cada renovación. La participación temprana a través del inventario, la incorporación del proveedor de DNS y la automatización programada de la validación de dominios proporciona a los equipos una hoja de ruta priorizada mucho antes de que entren en vigor los umbrales obligatorios.
Puntos clave
- La validez de los certificados TLS se reduce a 200 dÃas (2026), 100 dÃas (2027) y 47 dÃas (2029); la reutilización de DCV se reduce a 10 dÃas para 2029, según lo establecido por la propuesta SC-081v3 del Foro CA/Navegador.
- Con una validez de 47 dÃas y un perÃodo de reutilización de 10 dÃas, la propiedad del dominio debe volver a comprobarse aproximadamente 35 veces al año por dominio, lo que supera con creces la capacidad de validación manual.
- DCV persistente, el DNS-PERSIST-01 El método introducido por la votación SC-088v3 y permitido desde noviembre de 2025 permite revalidar un dominio contra un único registro TXT publicado una sola vez en _validation-persist, sin cambios en el DNS por renovación y sin pérdida de seguridad.
- Los conectores DNS automatizan los cambios DNS restantes; junto con la validación continua de dominio (DCV) persistente, permiten que la validación se ajuste a la frecuencia.
- CertSecure Manager v3.3 ayuda a las organizaciones a incorporar proveedores de DNS públicos y a ejecutar la automatización programada de DCV en un entorno independiente de las CA, antes de los plazos obligatorios.
Cómo puede ayudar Encryption Consulting
Encryption Consulting es especialista en criptografÃa aplicada y PKI. Además de proporcionar CertSecure Manager , nuestra práctica de servicios PKI ayuda a las organizaciones a implementar de principio a fin la transición a certificados con ciclos de vida más cortos, desde el inventario inicial hasta la validación de dominio totalmente automatizada e independiente de la CA. Ayudamos a los equipos a:
- Evalúe la preparación para los próximos 47 dÃas. Descubra todos los certificados de confianza pública, identifique las deficiencias en la detección que provocan interrupciones silenciosas y elabore una hoja de ruta de migración priorizada en función de los hitos de 2026 a 2029.
- Automatice la validación DNS-01. Incorpore a sus proveedores de DNS públicos y configure la validación de dominio programada e independiente de la CA, incluida la validación persistente de dominios (DNS-PERSIST-01) para dominios establecidos, de modo que las renovaciones se desvinculen del trabajo manual de DNS.
- Implemente e integre CertSecure Manager. Ponga en marcha la plataforma en todas sus CA públicas y privadas, con agentes de renovación para una renovación automática en servidores web, balanceadores de carga y aplicaciones internas.
- Diseñar y operar PKI. Esto abarca el diseño e implementación de PKI, junto con opciones gestionadas a través de PKI como servicio y HSM como servicio, incluyendo la protección de las claves de cuenta ACME que la validación continua de dominios (DCV) hace que sean de vital importancia para la seguridad.
- Manténgase alineado con los estándares y sea ágil en criptografÃa. Esto implica cumplir con las normas CA/Browser Forum, realizar validaciones conformes a las RFC y estar preparado para la era post-cuántica, de modo que la automatización que desarrolle ahora se mantenga durante la próxima transición.
Para evaluar su conjunto de certificados en función del plazo de 47 dÃas y elaborar una hoja de ruta para la automatización de DNS-01, póngase en contacto con el equipo de Servicios PKI de Encryption Consulting.
Conclusión
La trayectoria está definida. Para 2029, los certificados TLS públicos durarán 47 dÃas y la validación de dominios caducará cada 10 dÃas. Esto convierte lo que antes era un trámite anual en una tarea operativa continua. Las actualizaciones manuales de DNS y la validación por correo electrónico no pueden seguir este ritmo. La validación persistente de dominios (DNS-PERSIST-01) elimina el cambio de DNS por renovación para los dominios establecidos, y los conectores DNS automatizan los cambios restantes; juntos, permiten que la validación de dominios se adapte a la frecuencia de emisión en lugar de verse afectada por ella.
Las organizaciones que logren una transición fluida serán aquellas que se preparen antes de que entren en vigor los nuevos lÃmites. Inventariarán su infraestructura, incorporarán a sus proveedores de DNS y automatizarán la validación de dominios de forma programada e independiente de la CA, mientras que los certificados de 200 dÃas aún permiten cierto margen de ajuste. La validación de dominios se está convirtiendo en una infraestructura básica; el reto consiste en lograr que funcione correctamente antes de que la fecha lÃmite de 2027 obligue a implementarla.
Lecturas relacionadas de Encryption Consulting
Recursos adicionales sobre los plazos, protocolos y automatización mencionados anteriormente:
- El mandato del Foro CA/Navegador Cubre los recortes de validez, la fecha lÃmite de junio de 2026 para la doble EKU y los requisitos que conllevan.
- CA público vs. CA privado Explica cuándo usar cada opción y cómo crear automatizaciones para el plazo de 47 dÃas.
- Selección de un protocolo de inscripción para el certificado Compara ACME, EST, SCEP y CMP para certificados de corta duración.
- ¿Qué es el protocolo ACME? Explica cómo funciona realmente la validación de desafÃo-respuesta, incluido DNS-01.
- Clientes ACME en Linux Cubre temas como Certbot, acme.sh, la cobertura de proveedores de DNS y el papel que desempeña la gobernanza centralizada.
- Ampliación de las operaciones del ciclo de vida de los certificados mediante la automatización. Muestra cómo convertir las renovaciones frecuentes en un proceso automatizado y sin intervención manual.
- Administrador de CertSecure v3.3 Detalla las novedades que incorpora esta versión para una mayor frecuencia de renovación.
- Centralización de Let's Encrypt y la emisión de DNS-01 con CertSecure Manager Cubre la validación del desafÃo DNS-01 en todos los proveedores de DNS públicos, gestionada de forma centralizada.
- Los plazos que impulsan el cambio
- Por qué los certificados más cortos dificultan la validación manual del dominio.
- ¿Qué es la validación de control de dominio (DCV)?
- ¿Qué es la DCV persistente (DNS-PERSIST-01)?
- DCV tradicional frente a DCV persistente
- ¿Qué son los conectores DNS?
- Cómo funcionan conjuntamente los conectores DCV y DNS persistentes
- Directrices: qué hacer antes de que se acerquen las fechas lÃmite.
- CertSecure Manager v3.3: Automatización DNS-01 independiente de CA
- Puntos clave
- Cómo puede ayudar Encryption Consulting
- Conclusión
- Lecturas relacionadas de Encryption Consulting
