Automatización de la validación DNS con CertSecure Manager: DCV persistente y conectores DNS

Un certificado que antes se renovaba una vez al año ahora debe revalidarse aproximadamente cada cinco o seis semanas, y para marzo de 2029 ese intervalo se reducirá a cada 47 días. La validación persistente del control de dominio (DCV, por sus siglas en inglés) (DNS-PERSIST-01) y los conectores DNS son los dos controles que permiten que la validación del control de dominio se mantenga actualizada: la DCV persistente permite que un dominio se vuelva a verificar con un único registro DNS TXT publicado una sola vez, y los conectores DNS automatizan los cambios DNS restantes, de modo que los equipos de certificación puedan cumplir con el calendario de validez cada vez más ajustado del CA/Browser Forum sin necesidad de realizar trabajo manual de DNS en cada renovación.

Esta guía abarca la función de cada capacidad, los plazos exactos que obligan al cambio, los requisitos previos y el flujo de trabajo paso a paso para implementarlos, los equipos responsables de su ejecución y las métricas que muestran si la automatización está funcionando realmente.

Respuesta rápida: ¿Qué son los conectores DCV y DNS persistentes?

La validación persistente del dominio (DNS-PERSIST-01) permite al propietario de un dominio publicar un registro TXT en _validation-persist.[dominio] que una CA verifica automáticamente en cada renovación, eliminando así el trabajo de DNS por renovación. Los conectores DNS automatizan los cambios DNS restantes a través de la API del proveedor. En conjunto, son necesarios para mantener el calendario de validez TLS de 47 días del CA/Browser Forum (marzo de 2029, Ballot SC-081v3) sin un esfuerzo manual proporcional.

Puntos Clave

• La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS públicos a 200 días el 15 de marzo de 2026, a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029, mientras que los períodos de reutilización de DCV se reducen según el mismo calendario hasta los 10 días.
• La validación persistente de dominio (DNS-PERSIST-01), permitida desde noviembre de 2025 según la propuesta SC-088v3, permite que un dominio se vuelva a validar con un único registro TXT publicado una sola vez, eliminando por completo el trabajo de DNS por renovación para los dominios establecidos.
• Los conectores DNS automatizan los cambios DNS restantes, incluidos los nuevos dominios y la configuración inicial, comunicándose directamente con la API del proveedor DNS en lugar de hacerlo a través de un ticket manual.
• La encuesta Trust Pulse de DigiCert (2 de julio de 2025) reveló que el 45 % de las empresas sufrieron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % atribuyeron una interrupción específicamente a un certificado caducado.
• Los equipos de PKI, seguridad, plataforma y cumplimiento normativo son responsables cada uno de una parte distinta de esta implementación; la matriz de propietarios/acciones y la lista de verificación de requisitos previos que se muestran a continuación detallan exactamente quién hace qué.

Ir a: Resumen ejecutivo | Flujo de trabajo de implementación | Matriz de requisitos previos a la acción | Matriz de propietarios/acciones | Métricas de éxito | CertSecure Manager v3.3 | Preguntas frecuentes

¿A quién debería importarle la persistencia de los conectores DCV y DNS?

Las consecuencias operativas del calendario de reducción de validez del CA/Browser Forum afectan simultáneamente a los equipos de certificados, DNS, arquitectos de seguridad, ingenieros de plataforma y funciones de cumplimiento. Cada uno presenta un punto de fallo específico. Un equipo de certificados que automatiza la renovación pero no la validación DNS se enfrenta a problemas cuando expira el plazo de reutilización de DCV. Un equipo DNS que concede acceso a la API pero no supervisa la rotación de credenciales del conector genera un fallo silencioso. Con una validez de 47 días a partir de marzo de 2029, cada deficiencia produce fallos de renovación con una frecuencia ocho veces mayor que la anterior a 2029.

Rol	POR QUÉ ES IMPORTANTE	Acción
Equipos de PKI y certificados	Poseer el inventario de certificados y las relaciones con las CA; identificar qué dominios califican para la DCV persistente y secuenciar el despliegue por riesgo (primero los dominios SAN y comodín, ya que conllevan la mayor sobrecarga de coordinación); la encuesta Trust Pulse de DigiCert (2 de julio de 2025) encontró que el 45% de las empresas tuvieron tiempo de inactividad relacionado con certificados en el último año, y con una validez de 47 días, cada falla de validación manual produce una interrupción ocho veces más frecuentemente que antes; solo el 34% de las organizaciones tienen una vista completa y actualizada de sus certificados (informe PKI Under Pressure de DigiCert, 2 de junio de 2026), lo que hace que el descubrimiento sea el requisito previo que desbloquea todo lo demás.	Ejecutar un pase completo de descubrimiento de certificados usando Administrador de CertSecure para crear un inventario etiquetado por el propietario de cada certificado de confianza pública y su lista SAN; usar CBOM seguro para extender el descubrimiento más allá de los certificados TLS a todo el conjunto criptográfico; priorizar primero los dominios SAN y comodín para la incorporación persistente de DCV; confirmar qué CA emisoras ya admiten DNS-PERSIST-01 y usar DNS-01 convencional con conectores para aquellas que aún no lo hacen.
Equipos de plataforma e infraestructura	El acceso al proveedor de DNS propio y la gestión de credenciales de API son requisitos previos para la incorporación de conectores; la parte más lenta de la validación basada en DNS no suele ser la búsqueda de DNS, sino la transferencia humana entre los equipos de certificados y DNS; una renovación que falla porque no se procesó a tiempo un ticket de cambio de DNS produce exactamente las interrupciones que midió la encuesta de DigiCert de julio de 2025; las credenciales de API del conector deben tener un alcance correcto, rotarse según lo programado y probarse de forma proactiva, en lugar de descubrir que han caducado solo cuando falla una renovación.	Solicite credenciales de API con ámbito y acceso de escritura de registros TXT para cada proveedor de DNS en uso (Route 53, Cloudflare, Azure DNS, Google Cloud DNS y cualquier otro); conecte cada proveedor a Administrador de CertSecure Utilizando la integración del conector DNS, compruebe que un ciclo de escritura, validación y eliminación de registros TXT se completa programáticamente sin generar un ticket antes de que cualquier certificado de producción dependa de él; programe la rotación trimestral de credenciales y pruebe cada conector después de la rotación para confirmar que sigue escribiendo registros correctamente.
Arquitectos de seguridad	Adquiera el modelo de gobernanza de credenciales y monitoreo que hace que la DCV persistente sea segura en lugar de crear una nueva superficie de ataque; la DCV persistente traslada el activo a proteger del acceso de escritura DNS (que debe estar disponible en cada renovación) a la clave de cuenta ACME (que solo se requiere para configurar el registro persistente); una clave de cuenta ACME comprometida o no monitoreada que respalda un registro persistente puede autorizar la emisión de certificados para un dominio establecido sin activar una alerta de cambio de DNS; el propio registro _validation-persist debe monitorearse para detectar modificaciones no autorizadas.	Agregue las claves de cuenta ACME que respaldan los registros DCV persistentes al programa de gestión y rotación de secretos existente de la organización antes de incorporar DCV persistente a gran escala; configure alertas de monitoreo en el registro TXT _validation-persist para cada dominio para que cualquier cambio inesperado active una investigación; defina el plan de acción de respuesta de registro persistente no autorizado (desactive la cuenta ACME según la Sección 7.5.2 de RFC 8555 para revocar la autorización de emisión inmediatamente); planifique la preparación de PQC para los algoritmos de clave ACME a través de Centro de Excelencia PQC y Preparación para PQC servicios
Equipos de cumplimiento	Es necesario confirmar que la actividad automatizada de DCV y del conector DNS se registre y sea auditable para los marcos regulados; DORA, NIS2, FedRAMP y CMMC requieren evidencia de quién validó qué dominio y cuándo; los procesos automatizados que no dejan rastro de auditoría incumplen este requisito con la misma seguridad que los manuales; el cronograma SC-081v3 del CA/Browser Forum (validez de 47 días para marzo de 2029) también implica que la evidencia de cumplimiento para DCV debe producirse con una frecuencia ocho veces mayor que la anterior a 2029, lo que hace que la recopilación manual de evidencia de auditoría sea insostenible por la misma lógica que hace insostenible la validación manual.	Confirme que la plataforma del ciclo de vida del certificado registra cada evento de DCV (dominio, método, marca de tiempo, cuenta de CA, resultado) con suficiente detalle para la evidencia de auditoría; asigne los registros de actividad de DCV y del conector a los requisitos de control del marco aplicable (Artículo 9 de DORA, Artículo 21 de NIS2, FedRAMP SC-12, Práctica CMMC CM.L2-3.4.2); exija que el período de retención de registros cumpla con los requisitos del marco antes de automatizar completamente DCV; evalúe PKI como servicio Para organizaciones donde las operaciones de PKI gestionadas incluyen el registro de auditoría integrado para la actividad de DCV.
CISO	Las interrupciones de certificados causadas por validaciones fallidas son operativamente equivalentes a las interrupciones por certificados caducados, pero más difíciles de diagnosticar porque el certificado parece válido y confiable, pero no se puede renovar; la encuesta Trust Pulse de DigiCert (2 de julio de 2025) reveló que el 37.5 % de las interrupciones relacionadas con certificados se debían a un certificado caducado, y más de la mitad causaron entre 5 y 24 horas de inactividad con pérdidas financieras de entre 50 000 y 250 000 dólares en el 31 % de las organizaciones afectadas; el calendario de reducción de validez del CA/Browser Forum es fijo independientemente de la preparación de la organización, lo que convierte la inversión en automatización anterior a 2026 en una decisión de reducción de riesgos en lugar de una actualización opcional.	Financiar el despliegue persistente de DCV y conectores DNS como una inversión para la reducción del riesgo operativo antes de que entren en vigor los umbrales de marzo de 2026 y marzo de 2027; exigir que la cobertura de automatización de certificados (porcentaje de la infraestructura TLS pública bajo DCV independiente de CA programado) se informe trimestralmente como un KPI a nivel de junta directiva; exigir que la protección de la clave de cuenta ACME se incluya en la revisión del programa de gestión de secretos; evaluar PKI como servicio Para organizaciones que necesitan una operación de ciclo de vida de certificados administrada con automatización DCV integrada y cobertura de conector DNS.

Resumen ejecutivo para líderes en seguridad, PKI, plataformas y cumplimiento normativo.

Si usted lidera alguna de estas funciones, aquí tiene la decisión que respalda este artículo y la lista de verificación de referencia rápida para ponerla en práctica.

• Equipos de PKI/certificados: Realizar un inventario del entorno TLS público, identificar qué dominios cumplen los requisitos para la validación de dominio persistente (DCV) y priorizar los dominios SAN y comodín para su incorporación en primer lugar.
• Equipos de seguridad: Trate la clave de cuenta ACME asociada a un registro persistente como una credencial sensible y añada el riesgo de interrupción del certificado al mismo nivel de supervisión que otros riesgos de disponibilidad.
• Equipos de plataforma/infraestructura: Conecte los proveedores de DNS a la plataforma de ciclo de vida de certificados mediante conectores basados ​​en API, de modo que los cambios de DNS ya no dependan de un ticket de gestión de cambios.
• Equipos de cumplimiento: Confirmar que la actividad automatizada de los conectores DCV y DNS se registre y sea auditable, ya que los entornos regulados (DORA, NIS2, FedRAMP, CMMC) necesitan pruebas de quién validó qué y cuándo.

Los plazos que impulsan el cambio

En abril de 2025, el Foro CA/Browser aprobó la propuesta SC-081v3 , «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, incluyendo los certificados DV, OV y EV, así como los certificados comodín y multidominio (SAN). El análisis de Sectigo del 14 de abril de 2025 sobre esta propuesta la presenta como un paso incremental, no como un cambio abrupto, hacia una gestión de certificados automatizada y preparada para la computación cuántica.

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 de dominios?

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 certificados se convierte en la norma. La pregunta es qué forma de automatización reduce al máximo el riesgo operativo.

Los datos que justifican la urgencia

Los cálculos anteriores no son teóricos. Investigaciones recientes del sector cuantifican con exactitud lo que sucede cuando la validación y la renovación no pueden seguir el ritmo de un calendario de certificados comprimido:

• El 45% de las empresas experimentaron interrupciones del servicio relacionadas con un incidente de certificado durante el último año, y el 37.5% atribuyeron una interrupción específicamente a un certificado caducado.Según DigiCert Encuesta de confianzaPublicado el 2 de julio de 2025. Más de la mitad de las organizaciones afectadas experimentaron entre 5 y 24 horas de inactividad, y el 31% reportó pérdidas financieras de entre 50,000 y 250,000 dólares.
• El 72% de las organizaciones experimentaron al menos una interrupción relacionada con certificados en el último año.Según CyberArk Informe sobre el estado de la seguridad de la identidad de las máquinas de 2025, que encuestó a 1,200 líderes de seguridad en seis países.
• Solo el 34% de las organizaciones tienen una visión completa y actualizada de sus certificados digitales.y casi el 75% están muy o extremadamente preocupados por las interrupciones causadas por certificados caducados, según DigiCert. “PKI bajo presión: el punto de inflexión para la modernización” Informe publicado el 2 de junio de 2026, basado en una encuesta realizada a más de 400 altos directivos de TI y seguridad.
• La emisión automatizada y validada por DNS ya es la norma.: La emisión automatizada de ACME de Let's Encrypt por sí sola representa más del 60% de todos los certificados TLS en uso, y más del 94% de todos los certificados emitidos hoy en día están validados por dominio, la mayoría emitidos instantáneamente por procesos automatizados, a partir del primer trimestre de 2026 (SSLreminder, “Estado de TLS en el primer trimestre de 2026”).

Los conectores DCV y DNS persistentes son los mecanismos que permiten que la validación de dominios se mantenga al día con esa transición hacia la emisión siempre automatizada, en lugar de convertirse en el próximo cuello de botella operativo una vez que se multiplique la frecuencia de renovación.

¿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.

Formato de registro TXT persistente

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 persistentes y DNS

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.

Automatización de DCV: Requisitos, modos de fallo y señales de monitorización

Utilice esta tabla para relacionar cada requisito de automatización de DCV con su método de validación, el modo de fallo cuando no se cumple el requisito, la señal de monitorización que detecta el fallo y la fuente de política autorizada. Los informes SC-081v3 y SC-088v3 del Foro CA/Browser se revisan trimestralmente y pueden actualizarse de forma independiente.

Requisito	Método de validación	Modo de fallo	Señal de monitoreo	Fuente de la política
El registro TXT persistente se resuelve correctamente desde todos los servidores de nombres autoritativos.	Consulta _validation-persist.[dominio] desde múltiples servidores DNS en diferentes regiones geográficas; confirma que todos los servidores DNS devuelven el mismo valor de registro; prueba con servidores DNS públicos (Google 8.8.8.8, Cloudflare 1.1.1.1); comprobación de validación DNS de la plataforma CLM	El retraso en la propagación del DNS o la brecha en la transferencia de zona provocan que la comprobación de validación de la CA falle desde una o más perspectivas; MPIC (CA/Browser Forum SC-067) ahora comprueba CAA y DCV desde múltiples ubicaciones de red, por lo que una inconsistencia visible desde una región provoca que la validación falle; la renovación falla incluso aunque el registro parezca correcto desde un único punto de vista.	Alerta de la plataforma CLM sobre fallo de validación de DCV para un dominio con un registro persistente; fallo de renovación de certificado correlacionado con errores de propagación de DNS en los registros de CA; alerta de monitorización de DNS sobre fallo de propagación de registro TXT a uno o más servidores de nombres autoritativos.	Boletín informativo SC-088v3 del Foro CA/Navegador (DNS-PERSIST-01, noviembre de 2025); Boletín informativo SC-081v3 (períodos de reutilización de DCV); Boletín informativo SC-067 (MPIC, septiembre de 2025)
Las credenciales de la API del conector DNS son válidas, tienen alcance y han sido probadas.	Pruebe un ciclo de escritura, validación y eliminación de registros TXT a través del conector antes de que cualquier certificado de producción dependa de él; confirme que las credenciales tengan acceso de escritura de registros TXT limitado a las zonas específicas involucradas (no a toda la cuenta); verifique la fecha de vencimiento de las credenciales; programe una rotación trimestral y realice una prueba después de la rotación.	El conector con credenciales de API de solo lectura, caducadas o con alcance excesivo falla silenciosamente en la siguiente ejecución programada; no se realiza el cambio de DNS; la comprobación de validación de la CA no encuentra ningún registro; la renovación falla; el fallo puede aparecer como un error de DCV en lugar de un error de credenciales, lo que ralentiza el diagnóstico.	Alerta de la plataforma CLM sobre fallo en la llamada al conector; registro de auditoría del proveedor DNS que muestra un fallo en la autenticación de la API; pico de fallos en la renovación del certificado correlacionado con la fecha de caducidad de las credenciales; panel de control de la comprobación del estado del conector que muestra la última marca de tiempo de escritura correcta.	Boletín del Foro CA/Browser SC-081v3 (períodos de reutilización de DCV que requieren validación automatizada); documentación de autenticación de la API del proveedor de DNS; política interna de rotación de credenciales
El registro persistente accounturi coincide con la cuenta ACME activa para cada CA emisora	Compare el valor accounturi en el registro TXT _validation-persist con la URL de la cuenta ACME devuelta por el punto final de la cuenta de la CA (RFC 8555 Sección 7.3); confirme que la cuenta está activa y no desactivada; pruebe que la CA acepta el registro persistente para una emisión de prueba.	El registro persistente creado para la cuenta incorrecta (CA incorrecta, cuenta migrada o URL de cuenta rotada) se valida para la CA incorrecta o no se valida en absoluto; la renovación del certificado falla; la CA devuelve un error de DCV que no especifica explícitamente la discrepancia de accounturi, lo que ralentiza el diagnóstico.	Fallo de validación de DCV de la plataforma CLM para un dominio con un registro persistente; respuesta de error de CA que indica cuenta no autorizada o registro no reconocido; alerta de la plataforma CLM sobre cambio de valor de accounturi del registro persistente desde la última auditoría.	Boletín del Foro CA/Navegador SC-088v3 Sección 3.2.2.4.22 (requisito del campo accounturi); RFC 8657 (estabilidad de la rotación de claves de cuenta ACME); RFC 8555 Sección 7.3.5 (estabilidad de la URL de la cuenta en rotaciones de claves)
El registro persistente se supervisa para detectar modificaciones no autorizadas.	Configure la supervisión DNS para el registro TXT _validation-persist.[dominio] que genere alertas ante cualquier cambio de valor; confirme que la plataforma de supervisión realiza comprobaciones desde múltiples ubicaciones geográficas; pruebe la alerta modificando temporalmente el valor del registro en una zona que no sea de producción.	Una modificación no autorizada del registro persistente pasa desapercibida; el registro modificado puede autorizar a una CA o cuenta ACME diferente a emitir certificados para el dominio; dado que el registro es permanente en lugar de por renovación, el período de exposición es continuo en lugar de estar limitado por un ciclo de renovación.	Alerta de monitorización DNS sobre cambio de valor del registro TXT _validation-persist; alerta de la plataforma CLM sobre cambio inesperado de CA o cuenta en el registro persistente; alerta del servicio de monitorización DNS externo sobre modificación de registro.	Boletín SC-088v3 del Foro CA/Browser (requisitos de seguridad de registros persistentes); RFC 8555 Sección 7.5.2 (desactivación de la cuenta ACME para revocar la autorización de emisión); Requisitos básicos del Foro CA/Browser Sección 4.9 (obligaciones de revocación de certificados)
La automatización de DCV se ejecuta según un cronograma alineado con el ritmo de renovación.	Confirme que la plataforma CLM esté configurada para ejecutar la validación del dominio antes de cada renovación con una frecuencia que se mantenga dentro del período de reutilización de DCV aplicable (200 días hasta marzo de 2027, 100 días hasta marzo de 2029, 10 días a partir de marzo de 2029); pruebe que DCV se ejecute automáticamente sin activación manual; confirme la programación independiente de la CA para que se aplique la misma automatización independientemente de qué CA pública emita el certificado.	La automatización de DCV no está programada o está configurada para una ventana de reutilización más larga que el límite aplicable; la evidencia de DCV de la CA caduca antes de la próxima renovación; la CA se niega a emitir porque los datos de validación del dominio están desactualizados; este modo de fallo se vuelve más frecuente a medida que se reduce la ventana de reutilización.	Alerta de la plataforma CLM sobre la caducidad de la evidencia DCV próxima a la fecha de renovación; fallo en la renovación del certificado que cita evidencia DCV caducada en los registros de CA; panel de control de la plataforma CLM que muestra dominios con una marca de tiempo de última ejecución de DCV anterior a la ventana de reutilización aplicable.	Boletín SC-081v3 del Foro CA/Browser (períodos de reutilización de DCV: 200 días en marzo de 2026, 100 días en marzo de 2027, 10 días en marzo de 2029); Sección 3.2.2.4 de los Requisitos Básicos del Foro CA/Browser (requisitos del método DCV)

Requisitos previos antes de la implementación

Confirme que estos elementos estén implementados antes de incorporar conectores DCV o DNS persistentes, para que el despliegue no se detenga a mitad de camino:

1. Un inventario de certificados actualizado. Necesitas una lista, respaldada por un proceso de descubrimiento, de todos los certificados de confianza pública y los dominios que cubren antes de poder decidir qué dominios cumplen los requisitos para la validación persistente del certificado de dominio (DCV).
2. Acceso mediante API a cada proveedor de DNS en uso. Los conectores DNS se autentican en la API del proveedor (Route 53, Cloudflare, Azure DNS, Google Cloud DNS y similares), por lo que se necesitan credenciales de API con permiso para escribir registros TXT, con un alcance limitado a las zonas implicadas.
3. Una cuenta de CA que admita ACME y, cuando esté disponible, DNS-PERSIST-01. Confirme cuáles de sus autoridades de certificación emisoras ya admiten la verificación de dominio persistente (DCV), ya que se trata de un método recientemente habilitado que las autoridades de certificación aún están implementando.
4. Un propietario designado para la aprobación del cambio de DNS. Incluso los cambios automatizados de DNS necesitan un propietario registrado definido para fines de auditoría, normalmente la plataforma o el equipo de infraestructura.
5. Una plataforma de gestión del ciclo de vida de los certificados como Administrador de CertSecure Capaz de programar verificaciones de dominio central (DCV) recurrentes y ejecutar llamadas al conector DNS, en lugar de scripts puntuales.

Flujo de trabajo de implementación paso a paso

Una vez cumplidos los requisitos previos mencionados, el despliegue consta de cinco pasos. En cada paso se indica el resultado que debería observarse antes de pasar al siguiente.

Paso 1: Inventariar el patrimonio del certificado.

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. Etiquete cada certificado con su dominio propietario, lista SAN y propietario empresarial. Resultado: un inventario completo y etiquetado del conjunto de certificados TLS públicos.

Paso 2: Incorporar proveedores de DNS

Conecte cada proveedor DNS que aloja sus zonas a la plataforma de gestión del ciclo de vida de los certificados mediante sus credenciales API, de modo que los registros de desafío DNS-01 se puedan crear y verificar mediante programación. Esto elimina la necesidad de transferir manualmente la información entre los equipos de certificados y DNS. Resultado: todos los proveedores DNS de la red están conectados y la plataforma puede generar un registro TXT de prueba sin necesidad de una solicitud manual.

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

Paso 3: Publicar el registro de validación persistente

Para los dominios que cumplan los requisitos, publique el registro TXT de un solo uso en _validation-persist.[dominio] con el formato mostrado anteriormente, utilizando el conector en lugar de un ticket DNS manual. Priorice los dominios SAN y comodín, ya que generan la mayor sobrecarga de coordinación con el modelo anterior. Resultado: el registro persistente se resuelve correctamente y la CA emisora ​​confirma que reconoce la cuenta.

Paso 4: Configurar la automatización programada de DCV

Configure la plataforma de ciclo de vida de certificados para que ejecute la validación de dominio recurrente, alineada con la frecuencia de renovación que requieren sus certificados, en lugar de activar la validación manualmente en cada renovación. Mantenga esta configuración independiente de la CA para que se aplique el mismo cronograma independientemente de la CA pública que emita un certificado determinado. Resultado: la validación de dominio se ejecuta automáticamente antes de cada renovación, sin intervención en cada ciclo.

Figura 2. Estado de validación programada del dominio DNS-01 en CertSecure Manager.

Paso 5: Validar, supervisar y establecer límites de seguridad para la reversión.

Confirme que un ciclo de renovación completo se complete de principio a fin sin intervención manual. A continuación, active la monitorización del registro persistente (los cambios inesperados son una señal de alerta) y de los fallos en las llamadas al conector. Documente la ruta de reversión antes de necesitarla. Resultado: al menos un ciclo de renovación automatizado completo se completa con éxito, con alertas activadas para el registro y el conector.

Guía de reversión y errores comunes

Errores comunes a tener en cuenta

• Retrasos en la propagación del DNS. Un registro TXT recién escrito que no se haya propagado a través de todos los servidores de nombres autorizados provocará que falle la comprobación de validación de la CA; incorpore una comprobación de propagación en el flujo de trabajo antes de activar la emisión.
• El alcance de las credenciales de la API es demasiado limitado o ha caducado. Un conector DNS con credenciales de API de solo lectura o caducadas fallará silenciosamente en la siguiente ejecución programada; rote y pruebe las credenciales según un calendario, no solo cuando falle una renovación.
• Registro persistente publicado con la cuenta de CA incorrecta. Debido a que el valor accounturi vincula el registro a una cuenta ACME específica, un registro creado para la cuenta incorrecta se validará para la CA incorrecta o no se validará en absoluto.
• No se realiza ningún seguimiento del registro persistente en sí. Dado que el registro autoriza la emisión de forma continua, un cambio inadvertido en el mismo tiene un impacto mayor que el que solía tener una validación puntual no realizada.

Retroceder de forma segura

Si es necesario revertir la validación persistente de dominio (DCV) para un dominio, elimine el registro TXT _validation-persist o desactive la cuenta ACME asociada (RFC 8555, Sección 7.5.2), lo que revoca la autorización de emisión de inmediato. Mantenga disponible la validación convencional DNS-01 como alternativa para cualquier dominio migrado a DCV persistente y pruebe dicha alternativa antes de utilizarla en producción. Para los conectores DNS, desactive la integración del proveedor específico en lugar de revocar el acceso a la API de toda la plataforma, de modo que otros proveedores sigan funcionando mientras soluciona el problema.

Matriz de requisitos previos para la acción

Requisito previo	Acción:	Equipo propietario
Inventario de certificados incompleto	Realizar el descubrimiento en redes públicas y privadas; etiquetar cada certificado con el dominio, la lista SAN y el propietario.	Equipo de PKI/certificados
Aún no se ha concedido acceso a la API del proveedor DNS.	Solicite credenciales de API con ámbito y permiso de escritura de registros TXT para cada proveedor.	Equipo de plataforma/infraestructura
CA aún no admite DNS-PERSIST-01	Confirme la compatibilidad con DCV persistente directamente con cada CA emisora; mientras tanto, utilice DNS-01 convencional con conectores.	Equipo de PKI/certificados
No hay propietario designado para los cambios automáticos de DNS.	Asigne y documente un propietario registrado para fines de auditoría.	Equipo de seguridad/cumplimiento
No hay automatización DCV programada en la plataforma de ciclo de vida	Configure la validación de dominio recurrente e independiente de la CA, alineada con la cadencia de renovación.	Equipo de PKI/certificados

Antes y después: Operaciones de validación de DNS

Paso operativo	Antes (manual)	Después (conectores DCV + DNS persistentes)
Solicitar un cambio de DNS	Se ha enviado una solicitud al equipo de redes y se encuentra en cola detrás de otras solicitudes de cambio.	La plataforma de certificados escribe el registro directamente a través de la API del proveedor.
Validación de la propiedad del dominio	Se repite en cada renovación, hasta aproximadamente 35 veces al año por dominio para el año 2029.	Registro publicado una sola vez para dominios establecidos; no se requiere trabajo de DNS por renovación.
Tiempo de respuesta de aprobación	De horas a días, dependiendo de los periodos de gestión de cambios.	Minutos, ya que no hay aprobación humana en la ruta DNS.
Punto de fallo bajo alta frecuencia de renovación	Un cambio de DNS omitido o retrasado provoca que la renovación falle.	La renovación se realiza independientemente del DNS, una vez que el registro persistente esté establecido.
Registro de auditoría	Repartidos por el sistema de gestión de incidencias, la consola DNS y el portal de la CA.	Centralizado en el conector de la plataforma del ciclo de vida del certificado y en los registros de DCV.

Tabla de decisiones: ¿Qué ruta de automatización DNS-01 se adapta mejor a su organización?

No todas las propiedades requieren el mismo punto de partida. Utilice la tabla a continuación para encontrar el siguiente paso adecuado según su entorno actual.

Tu situación	Ruta recomendada	Por qué
Propiedad pequeña (menos de 50 certificados públicos), cadencia de renovación anual en la actualidad	Continúe con la renovación manual o mediante guion a corto plazo, pero planifique una validez de 100 días para marzo de 2027.	El volumen de renovaciones aún es lo suficientemente bajo como para absorberlo manualmente, pero el umbral de 2027 cuadruplica aproximadamente la frecuencia de renovación.
Los cambios de DNS se realizan a través de un proceso de gestión de incidencias o de cambios.	Prioriza primero los conectores DNS.	Elimina la transferencia humana que se convierte en el punto de fallo cuando la validación debe repetirse cada pocas semanas.
Propiedades de gran tamaño o con uso intensivo de SAN/comodines que abarcan múltiples dominios.	Adopte la verificación de dominio persistente (DNS-PERSIST-01) para dominios establecidos, junto con conectores DNS para dominios nuevos.	Elimina por completo el trabajo de DNS por renovación para los dominios ya validados, reduciendo los cambios de DNS de cientos al año a una configuración única por dominio.
Entorno PKI multi-nube o híbrido que abarca múltiples CA públicas y privadas.	Implemente la automatización independiente de la CA, como CertSecure Manager v3.3, que combina la verificación de dominio programada, los conectores DNS y el registro de auditoría centralizado.	Garantiza una validación coherente y auditable, independientemente de la autoridad de certificación pública o privada que emita un certificado determinado, y evita tener que reconstruir el flujo de trabajo al consolidar autoridades de certificación o proveedores de servicios en la nube.

Matriz de propietarios y acciones por equipo

Equipo	Medioambiental	Acción clave
Equipo de PKI/certificados	Es propietario del inventario de certificados y de las relaciones con las CA.	Identificar qué dominios cumplen los requisitos para la validación continua de dominios (DCV) persistente y secuenciar el despliegue según el riesgo (SAN/comodín primero).
Equipo de seguridad	Posee protección de credenciales y claves.	Trate las claves de cuenta de ACME que se encuentran detrás de registros persistentes como credenciales confidenciales; supervise los cambios no autorizados.
Equipo de plataforma/infraestructura	Posee acceso al proveedor de DNS y credenciales de API.	Otorgar y rotar credenciales de API DNS con ámbito; conectar cada proveedor a la plataforma de ciclo de vida
Equipo de cumplimiento	Posee evidencia de auditoría para marcos regulados.	Confirme que la actividad de DCV y del conector se registre, conserve y asigne a los requisitos de control de DORA, NIS2 o FedRAMP/CMMC.

Métricas de éxito a seguir tras la implementación

Realiza un seguimiento de estas métricas antes y después de la implementación para que el impacto de la automatización sea medible en lugar de simplemente supuesto. Si dispones de datos reales de tu propio entorno, infórmalos trimestralmente en lugar de presentarlos como una cifra única.

• Tiempo de renovación ahorrado por certificado, comparando la coordinación DNS manual con la validación basada en el conector.
• Número de certificados bajo automatización DCV programada e independiente de la CA, como porcentaje del total de TLS públicos.
• Reducción de tickets de cambio manual de DNS Presentado con fines de validación del certificado.
• Interrupciones o incidentes que estuvieron a punto de ocurrir relacionados con certificados., con un seguimiento trimestral en comparación con la línea de base previa a la automatización.
• Tiempo de implementación para incorporar un nuevo proveedor de DNS o dominio al flujo de trabajo automatizado.

No hemos incluido aquí una cifra de referencia específica de primera mano para estas métricas, ya que preferimos informar un número verificado de una implementación completada en lugar de una estimación. Si realiza un seguimiento interno de estas métricas, nuestro equipo de Servicios PKI puede ayudarle a establecer una línea base y a generar informes.

Qué hacer a continuación

• Equipos PKI: Ejecute ahora una comprobación de detección y marque todos los certificados que caduquen después del 15 de marzo de 2026 para darles prioridad en la migración.
• Equipos de seguridad: Agregue las claves de cuenta de ACME a su programa de monitoreo de secretos existente antes de incorporar la verificación de dominio persistente a gran escala.
• Equipos de plataforma: Solicitar acceso a la API del proveedor de DNS este trimestre para que la incorporación del conector no se vea bloqueada posteriormente por un retraso en la acreditación.
• Equipos de cumplimiento: Confirme que su marco de auditoría ya acepta los registros DCV automatizados como evidencia, o bien, señale la deficiencia ahora.

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 mayor 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, el descubrimiento, la emisión, la renovación y la validación se gestionan desde la misma consola, que es precisamente la misma que se muestra en los pasos de implementación anteriores, donde se explican la incorporación del proveedor DNS y las pantallas de DCV programadas.

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.

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.

Cómo puede ayudar la consultoría de cifrado

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:

• Evaluar la preparación para la obtención del certificado TLS en 47 días. Descubra todos los certificados de confianza pública, identifique las deficiencias en la detección de certificados que provocan interrupciones silenciosas y elabore una hoja de ruta de migración priorizada en función de los hitos de 2026 a 2029.
• Automatizar 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 DCV persistente (DNS-PERSIST-01) para dominios establecidos, de modo que las renovaciones se desvinculen del trabajo manual de DNS.
• Implementar e integrar CertSecure Manager. Implemente la plataforma en todas sus autoridades de certificación 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.
• Desarrollar la agilidad en el ámbito de las criptomonedas y la preparación para el control de calidad de las criptomonedas (PQC). Esto significa cumplimiento con CA/Browser Forum, validación alineada con RFC y preparación post-cuántica basada en nuestra Centro de Excelencia PQC y 9 fases Preparación para PQC hoja de ruta, respaldada por una empresa viva CBOM seguro inventario de cada activo criptográfico en su patrimonio, para que la automatización que cree ahora se mantenga durante la próxima transición. CBOM: del inventario a la inteligencia La guía explica cómo convertir ese inventario en un programa práctico de criptoagilidad.

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.

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.
• Guía de migración a la criptografía postcuántica (9 fases) Describe la hoja de ruta para la transición del algoritmo, que sigue a los cambios actuales en la duración y la validación de los certificados.
• Cómo crear un inventario criptográfico (CBOM) Este artículo amplía la disciplina de descubrimiento, desde los certificados TLS hasta la totalidad de su infraestructura criptográfica.
• CBOM: Del inventario a la inteligencia Muestra cómo convertir un inventario criptográfico en un programa continuo de agilidad criptográfica y preparación para el control de calidad de procesos (PQC).

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.

Esta publicación se revisa trimestralmente, teniendo en cuenta los calendarios de políticas SC-081v3 y SC-088v3 del Foro CA/Browser, y de inmediato cuando el Foro CA/Browser actualiza los períodos de reutilización de DCV, agrega nuevos requisitos de DCV persistentes o un proveedor importante de DNS cambia el comportamiento de autenticación de la API.

Preguntas frecuentes

¿Cuál es la principal conclusión de esta guía sobre DCV persistente y conectores DNS?

La validez de los certificados TLS públicos se reducirá a 47 días para marzo de 2029, lo que obliga a verificar la propiedad del dominio aproximadamente 35 veces al año por dominio. La validación persistente del dominio (DNS-PERSIST-01) elimina el trabajo de DNS por renovación para los dominios establecidos mediante el uso de un único registro TXT permanente, y los conectores DNS automatizan los cambios DNS restantes. En conjunto, estas soluciones permiten que la validación del dominio se adapte a la frecuencia de emisión en lugar de convertirse en el próximo cuello de botella.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales?

La gestión del ciclo de vida de los certificados ya presenta problemas de visibilidad: un estudio de DigiCert de 2026 reveló que solo el 34 % de las organizaciones tienen una visión completa y actualizada de sus certificados. Dado que la frecuencia de renovación se multiplicará por ocho para 2029, cualquier paso manual en la validación, especialmente la coordinación DNS, se convertirá en una fuente proporcionalmente mayor de renovaciones omitidas e interrupciones, a menos que se automatice con antelación.

¿Qué equipos son responsables de poner en práctica estas directrices?

Por lo general, cuatro equipos comparten esta tarea: el equipo de PKI o de certificados se encarga del inventario y las relaciones con las CA; el equipo de plataforma o infraestructura se encarga del acceso al proveedor de DNS y la incorporación de conectores; el equipo de seguridad se encarga de proteger las claves de cuenta ACME en las que se basa la validación continua de dominios (DCV persistente); y el equipo de cumplimiento se encarga de garantizar que la actividad de validación automatizada se registre con fines de auditoría. La matriz de responsabilidad/acción anterior detalla esta tarea.

¿Qué riesgos aumentan si este tema se aborda manualmente?

La encuesta Trust Pulse de DigiCert reveló que el 45 % de las empresas sufrieron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % de estos incidentes se debieron directamente a un certificado caducado; más de la mitad de estos incidentes provocaron entre 5 y 24 horas de inactividad. La coordinación manual del DNS es el punto de fallo más común, ya que la validación debe repetirse cada pocas semanas en lugar de una vez al año, dado que un solo cambio de DNS omitido o retrasado puede provocar que la renovación falle.

¿Cómo reduce la automatización el riesgo de interrupción de los certificados?

La automatización elimina la intervención humana, la cola de tickets y el plazo de aprobación que actualmente existen en el proceso DNS. La verificación de dominio persistente elimina por completo el paso DNS para los dominios establecidos, y los conectores DNS ejecutan cualquier cambio DNS restante a través de la API del proveedor en minutos, en lugar de horas o días. Dado que la renovación ya no depende de que una persona complete un cambio DNS a tiempo, se elimina el modo de fallo más común que provoca las interrupciones de certificados.

¿Qué métricas deberían monitorizar los equipos tras la implementación?

Realice un seguimiento del tiempo de renovación ahorrado por certificado, el porcentaje del entorno TLS público bajo automatización DCV programada e independiente de la CA, la reducción de incidencias de cambio de DNS manuales, las interrupciones o cuasi fallos relacionados con certificados en comparación con una línea base previa a la automatización, y el tiempo de implementación para la incorporación de nuevos proveedores de DNS o dominios. Informe estos datos trimestralmente para que la tendencia, y no solo una instantánea aislada, muestre si la automatización se mantiene a medida que aumenta la frecuencia de renovación.

¿Cómo se relaciona esto con la preparación para la certificación TLS en 47 días?

El calendario de la propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS a 200 días el 15 de marzo de 2026, a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029, con periodos de reutilización de DCV que se reducen a 10 días en el mismo periodo. Los conectores DCV y DNS persistentes son los mecanismos específicos que permiten alcanzar este ritmo operativo sin un aumento proporcional del trabajo manual de DNS.

¿Cómo debe gestionarse esto en entornos PKI híbridos o multinube?

Utilice una plataforma de ciclo de vida de certificados independiente de la CA, como CertSecure Manager, que aplique la misma lógica de DCV programada y conector DNS independientemente de la CA pública o privada que emita un certificado determinado y de la nube que aloje la zona DNS. Esto evita tener que reconstruir el flujo de trabajo de validación cada vez que se vuelve a emitir un certificado desde una CA diferente o cuando una zona DNS cambia de proveedor, algo común en entornos PKI híbridos y multinube.

¿Qué requisitos previos son necesarios antes de la implementación?

Necesitas un inventario de certificados actualizado y etiquetado por su propietario; credenciales de API con acceso de escritura a registros TXT para cada proveedor DNS en uso; confirmación de qué CA emisoras admiten DNS-PERSIST-01 actualmente; un propietario designado para la aprobación automatizada de cambios DNS; y una plataforma de ciclo de vida de certificados capaz de programar la verificación de control de dominio (DCV) recurrente y ejecutar llamadas al conector DNS. La sección de requisitos previos anterior describe cada uno de estos aspectos en detalle.

¿Qué errores comunes deben evitar los equipos?

Los errores más frecuentes son: publicar un registro persistente con la cuenta ACME incorrecta (la discrepancia en accounturi provoca que la CA rechace el registro silenciosamente); no supervisar el registro _validation-persist para detectar cambios no autorizados (un registro permanente es un objetivo de mayor valor que un registro de renovación); no realizar la comprobación de propagación de un registro TXT recién escrito antes de activar la emisión (el retraso en la propagación de DNS provoca que la comprobación multiperspectiva basada en MPIC de la CA falle desde una región); y no rotar las credenciales de la API del conector DNS en un calendario (las credenciales caducadas fallan silenciosamente en la siguiente ejecución programada, no cuando caducan).

¿Qué se debe actualizar trimestralmente para la gobernanza de la automatización de DCV?

Trimestralmente: confirmar que todos los registros persistentes se resuelvan correctamente y coincidan con las cuentas ACME autorizadas; rotar y probar las credenciales de la API del conector DNS; revisar los registros de errores de llamadas al conector del trimestre anterior; auditar los nuevos dominios agregados desde la última revisión para la cobertura de registros persistentes; verificar las directrices SC-081v3 y SC-088v3 del Foro CA/Navegador para actualizaciones de los períodos de reutilización de DCV o los requisitos de registros persistentes; y confirmar la planificación de preparación de PQC para los algoritmos de clave ACME a través del Centro de Excelencia de PQC . Esta publicación se revisa trimestralmente según el calendario de políticas activas del Foro CA/Navegador.