Dominio personalizado atascado en la validación SSL

Has añadido el registro. dig lo muestra. La plataforma sigue indicando que está pendiente, y lleva así una hora. Que un dominio personalizado se quede atascado en la validación resulta especialmente frustrante porque todas las comprobaciones que puedes ejecutar por tu cuenta parecen correctas.

Hay cuatro causas, todas mecánicas, y el orden siguiente permite encontrarlas más rápido.

Primero: qué hace realmente la validación

Antes de emitir un certificado, una autoridad certificadora debe comprobar que controlas el nombre. Hay dos métodos habituales, y cuál utilice tu plataforma determina qué puede fallar:

• HTTP-01 — la CA solicita http://your-domain/.well-known/acme-challenge/<token> y espera una cadena específica. Esto requiere que las solicitudes HTTP sin cifrar a tu dominio lleguen a la plataforma.
• DNS-01 — la CA busca un registro TXT. Esto requiere que el registro exista y sea visible para el resolver de la CA, que no tiene por qué ser el mismo que has consultado.

Casi todas las validaciones atascadas se deben a algo que se interpone entre la CA y uno de esos dos elementos.

Causa 1: un proxy delante del challenge

Esta es la causa más habitual cuando el dominio está detrás de una CDN, y resulta realmente confusa porque normalmente el proxy es precisamente lo que querías.

Si tu registro DNS está proxificado en lugar de apuntar directamente a la plataforma, la solicitud HTTP-01 de la CA termina en el proxy. El proxy sirve su propio certificado, aplica sus propias reglas y puede devolver una redirección, una página de challenge o un 404; ninguno de ellos contiene el token que la CA está esperando.

La solución es permitir el paso del challenge:

• Desactiva el proxy (pon el registro en modo grey-cloud) hasta que se emita el certificado y vuelve a activarlo después.
• O excluye /.well-known/acme-challenge/* de cualquier regla de redirección o acceso.

El problema es que las protecciones del tipo «Always Use HTTPS» y «Under Attack» interrumpen HTTP-01 aunque, desde el navegador, el sitio parezca funcionar perfectamente.

Causa 2: el tipo de registro incorrecto

Dos errores explican la mayoría de los casos restantes:

Un registro A que apunta a una dirección que cambia. Si la plataforma te ha dado un hostname, usa un CNAME. Copiar la IP actual en un registro A funciona hasta que la dirección cambia.

Un CNAME en el apex de la zona. example.com no puede contener legalmente un CNAME junto con sus registros SOA y NS. Algunos proveedores ofrecen ALIAS, ANAME o «CNAME flattening» para solucionar esto; otros no. Si el tuyo no lo ofrece, usa un subdominio — app.example.com — y redirige el apex.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

Si ambos comandos devuelven una respuesta vacía, nada de lo demás importa todavía.

Causa 3: una propagación que no estás midiendo

dig, sin argumentos, consulta tu resolver, que puede haber almacenado en caché la respuesta que acabas de crear o, peor aún, el NXDOMAIN de antes de que la crearas. Una entrada negativa en caché con un TTL largo es un motivo muy habitual de que una validación falle durante una hora y después funcione sin intervención alguna.

Consulta directamente los servidores autoritativos y también un resolver público para comprobar lo que probablemente verá la CA:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Si la respuesta autoritativa es correcta y la de los resolvers públicos no, estás esperando a que venza el TTL y no hay nada que solucionar.

Causa 4: CAA rechaza al emisor

Este caso es poco frecuente, invisible en las comprobaciones DNS normales y completamente silencioso cuando ocurre.

Un registro CAA de tu dominio indica qué autoridades certificadoras pueden emitir certificados para él. Si tienes uno —a menudo heredado de una configuración antigua o añadido por recomendación de un análisis de seguridad— y no incluye la CA que utiliza tu plataforma, la emisión falla. El único lugar donde se indica es en los logs de la CA, a los que no tienes acceso.

dig +short example.com CAA
dig +short app.example.com CAA

Una respuesta vacía significa que no hay restricciones, lo cual está bien. Si aparecen registros, añade la CA que utiliza tu plataforma o elimina la restricción.

El orden que lo encuentra más rápido

1. Ejecuta dig contra un resolver público. Si no hay respuesta, el registro es incorrecto o aún no se ha propagado; detente aquí.
2. Comprueba si el registro está proxificado. Si lo está, desactiva el proxy o excluye la ruta de ACME.
3. Comprueba CAA tanto en el apex como en el subdominio.
4. Solo entonces considera que el problema está en la plataforma.

El noventa por ciento de las validaciones atascadas termina en el paso 1 o el paso 2.

Cómo funciona en Dockup

Dos decisiones de diseño eliminan la mayor parte de las dudas.

El registro DNS se crea automáticamente. Si tu zona está en Cloudflare y has conectado la cuenta, al añadir un dominio se escribe el registro directamente en lugar de obligarte a copiar un valor manualmente:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

Esto elimina toda una clase de errores tipográficos y de tipo de registro: la plataforma sabe si necesita un CNAME o un registro A y crea el correcto.

La concesión requiere dos permisos. Zone:Read y DNS:Edit, y nada más. Dockup no puede leer tus otras zonas, cambiar la configuración de la cuenta ni modificar nada que no le hayas autorizado. Conectar la automatización de DNS no debería requerir entregar una cuenta completa.

El estado de la verificación y del certificado se muestra por dominio, en lugar de como un único estado agregado, de modo que «DNS verificado pero TLS pendiente» se entiende tal como es: dos pasos independientes, uno de los cuales ya ha terminado.

Preguntas frecuentes

¿Cuánto debería tardar la emisión del certificado? Normalmente, menos de un minuto una vez que el DNS resuelve correctamente. Si lleva pendiente más de unos quince minutos, hay algo que la está bloqueando; no es simplemente lentitud.

¿Por qué mi dominio funciona en el navegador, pero la validación falla? Porque el navegador sigue redirecciones y utiliza HTTPS, mientras que el challenge no hace ninguna de las dos cosas. Un proxy que sirve tu sitio perfectamente puede tragarse la solicitud ACME HTTP sin cifrar.

¿Puedo usar un CNAME en mi dominio raíz? No en el DNS estándar. Usa una función del proveedor, como ALIAS o CNAME flattening, o apunta el apex a un subdominio mediante una redirección.

¿Qué es un registro CAA y necesito uno? Restringe qué autoridades certificadoras pueden emitir certificados para tu dominio. No necesitas uno, pero si tienes uno que omite la CA de tu plataforma, la emisión falla silenciosamente.