TLS de dominio propio para enlaces cortos: listo en 5 minutos

Configurar un dominio propio con HTTPS requiere un registro TXT, un registro CNAME y una espera corta. Añades el nombre de host en Elido, copias los dos valores DNS que te da, y el certificado TLS se emite automáticamente la primera vez que alguien abre un enlace en ese dominio. La parte lenta es la propagación del DNS, que controlas con el TTL. Este artículo recorre los cinco pasos y después explica la maquinaria, para que sepas dónde mirar cuando un paso se atasca.

Todo lo que sigue se comprobó contra el código y el panel actuales de Elido el 2026-10-09. Cuando una función relacionada todavía no está construida, el artículo lo dice.

Por qué importa el TLS en un enlace corto

Un enlace corto es una redirección, y la respuesta de redirección es toda la carga útil. Un 301 o 302 con una cabecera Location lleva tu URL de destino. Si la primera petición viaja por HTTP sin cifrar, cualquiera en la ruta de red puede leer ese destino antes de que el navegador lo siga.

Los códigos QR lo empeoran. Quien escanea un código en un escaparate o en un cartel no tiene relación previa con la URL, así que la barra de direcciones es la única señal de confianza que recibe. Una advertencia del navegador al escanear es la peor primera impresión posible, y ya has pagado la tirada de impresión.

En los dominios cortos compartidos de Elido el certificado pertenece a Elido, así que el candado es real pero el nombre que figura en él no es el tuyo. En go.acme.com el nombre es tuyo. Para los fundamentos de DNS y TLS que hay detrás, consulta el artículo fundamental sobre enlaces cortos con dominio propio.

Paso 1: elige el nombre de host

Elige un subdominio corto que controles y no uses para nada más: go.example.com, links.example.com o similar. El prefijo aparece en cada enlace que envías, así que cuanto más corto, mejor.

Usa un subdominio, no la raíz. La RFC 1034 sección 3.6.2 dice que un nombre con un CNAME no puede contener otros datos, y la raíz de una zona siempre contiene registros SOA y NS, así que un CNAME allí no está permitido. Algunos proveedores de DNS lo simulan con registros ALIAS o aplanados, pero esos responden con direcciones IP en lugar de un CNAME. La verificación de Elido pide el CNAME en sí, así que una raíz aplanada no pasará.

Al registrar el nombre se aplican dos reglas más. El nombre de host debe ser un nombre de dominio completo en minúsculas, y los nombres bajo elido.me o elido.app están reservados.

Paso 2: añade el dominio en Elido

Abre Domains en la barra lateral del panel, escribe el nombre de host y haz clic en Add domain. Marca la casilla de comodín solo si quieres que funcione cada subdominio de ese nombre, como en *.go.example.com. Normalmente no hace falta. Elido muestra entonces los dos registros DNS con un botón de copiar junto a cada uno.

El mismo paso a través de la API, para scripts de incorporación o espacios de trabajo de clientes:

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"hostname": "go.example.com", "is_wildcard": false}'

La llamada necesita un rol que pueda gestionar dominios. Un dominio nuevo vuelve con el estado pending, un verify_token y un objeto instructions con los valores exactos de los registros:

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending",
    "is_wildcard": false
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

Los dominios propios requieren un plan de pago. Intenta registrar uno en un espacio de trabajo Free, por encima del número de dominios de tu plan o con una suscripción en pausa o cancelada, y la API responde 402. Es el código que yo trataría primero en cualquier script de onboarding, porque es el que un cliente se encuentra el primer día. Un nombre de host duplicado recibe 409. Las agencias que gestionan muchos dominios de clientes deberían leer la página de soluciones para agencias para conocer el modelo de espacios de trabajo.

Paso 3: publica los dos registros DNS

Añade ambos registros en tu proveedor de DNS, exactamente como se muestran:

go.example.com                  CNAME  edge.elido.me.
_elido-verify.go.example.com    TXT    "verify=<your-token>"

El CNAME enruta el tráfico a Elido. El registro TXT demuestra que eres el dueño de la zona. Ambos son obligatorios, y el valor del TXT debe coincidir exactamente con el token.

En un registro comodín, el CNAME pasa a ser *.go.example.com, mientras que el registro TXT se queda en _elido-verify.go.example.com, en el nombre padre sin el asterisco.

Fija un TTL de 300 segundos en ambos registros si tu proveedor lo permite. Muchas zonas usan 3600 segundos por defecto, y un TTL largo es lo que convierte un trabajo de cinco minutos en una hora.

Una nota sobre proveedores importa más que las demás. Si usas Cloudflare, deja el CNAME en solo DNS. La documentación de Cloudflare dice que un registro con proxy se responde con las propias direcciones IP de Cloudflare en lugar del contenido del registro (consultada el 2026-10-09). Por tanto, un nombre con proxy nunca devuelve el CNAME que busca Elido, y la verificación no pasará.

Paso 4: espera la verificación

No necesitas hacer clic en nada. Un proceso en segundo plano dentro de la API de Elido comprueba cada dominio pendiente con un temporizador, de 30 segundos por defecto, usando el resolvedor público de Google en 8.8.8.8. Solo da por bueno el dominio cuando se cumplen ambas condiciones:

1. El registro TXT en _elido-verify.<hostname> contiene exactamente verify=<token>.
2. El nombre de host tiene un CNAME que se resuelve al destino edge de Elido.

Cuando ambas se cumplen, el estado cambia a verified. Consúltalo tú mismo si estás automatizando la configuración:

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

Para saltarte la espera hasta el siguiente ciclo, envía POST .../domains/42/verify. Devuelve 202 y pasa el dominio al principio de la cola. Un dominio que permanece pendiente durante 24 horas se marca como failed con el motivo "verification timeout", y la misma llamada de verificación devuelve un dominio fallido a pendiente para que puedas reintentar tras corregir el DNS.

Si se atasca, consulta los registros de la misma forma que lo hace el verificador:

dig @8.8.8.8 TXT _elido-verify.go.example.com +short
dig @8.8.8.8 CNAME go.example.com +short

El primero debería imprimir "verify=<your-token>". El segundo debería imprimir edge.elido.me., con el punto final incluido.

Paso 5: la primera petición emite el certificado

Cuando el estado es verified, no te queda nada por hacer. Elido no emite certificados por adelantado. La capa TLS emite uno bajo demanda, la primera vez que un navegador abre una conexión TLS para tu nombre de host.

Antes de pedirle nada a Let's Encrypt, el edge llama a una comprobación de autorización en la API de Elido. La respuesta es afirmativa solo si el nombre de host está en estado verified o active, o si entra dentro de un registro comodín verificado. Cualquier otra respuesta, incluido un nombre desconocido, rechaza el handshake y no se solicita ningún certificado. Esa barrera es lo que impide que un desconocido apunte un millón de nombres de host a Elido y agote los límites de frecuencia de la autoridad de certificación.

Cuando la comprobación pasa, la emisión usa el desafío HTTP-01 de la RFC 8555: la autoridad de certificación pide un token en /.well-known/acme-challenge/ de tu nombre de host por HTTP sin cifrar, el edge lo responde, y el certificado se emite y se guarda en caché. El primer visitante espera un instante por esto. Las peticiones posteriores reutilizan el certificado en caché.

Un hábito práctico: abre https://go.example.com tú mismo justo después de la verificación, para que el certificado exista antes de que un cliente o un escaneo de QR sea la primera petición.

Pasa el id del dominio como domain_id al crear un enlace. El enlace está activo en https://go.example.com/<slug> de inmediato. La página Domains también muestra los clics de 30 días por nombre de host. La referencia completa, incluida la guía sobre CAA, está en la guía de dominios propios, y la descripción del producto en la página de la función de dominios propios.

Qué significan los valores de estado

En la versión actual un dominio sano permanece en verified. El valor active existe en el modelo de datos y en el filtro del panel, y la barrera del certificado acepta ambos, pero por ahora nada mueve un dominio a él.

Errores comunes

Registros CAA que excluyen a Let's Encrypt. Un registro CAA limita qué autoridades pueden emitir para un nombre, y los subdominios lo heredan (consultado el 2026-10-09). Si tu zona tiene example.com CAA 0 issue "digicert.com", la emisión para go.example.com se rechaza. Añade go.example.com CAA 0 issue "letsencrypt.org" o amplía el registro del vértice.

Un proxy o CDN delante del CNAME. La nube naranja de Cloudflare es el caso habitual, tratado en el paso 3. Cualquier capa que responda al DNS o al HTTP en tu nombre rompe tanto la comprobación del CNAME como el desafío HTTP-01.

Los comodines no son certificados comodín. Según la documentación de tipos de desafío de Let's Encrypt, HTTP-01 no puede emitir certificados comodín, y DNS-01 necesita acceso de escritura a tu zona (consultada el 2026-10-09). Así que un registro comodín cubre el enrutamiento de cada subdominio, pero client1.go.example.com y client2.go.example.com obtienen cada uno su propio certificado en el primer uso. Let's Encrypt limita los certificados nuevos por dominio registrado a 50 cada 7 días (consultado el 2026-10-09), así que incorporar cientos de subdominios nuevos en una semana requiere planificación.

Quitar el CNAME más adelante. Hoy la comprobación de DNS solo se ejecuta mientras un dominio está pendiente. Una vez verificado, Elido no vuelve a comprobarlo, así que un CNAME eliminado se manifiesta como redirecciones que fallan y renovaciones de certificado que fallan, no como un cambio de estado ni una notificación. Supervisa el registro por tu lado. Una comprobación de salud periódica con un estado degradado y un periodo de gracia está planificada, no construida.

Marius Voß es DevRel + edge infra en Elido. Es responsable de la ruta de redirección y del flujo de dominios propios.

Relacionado en el blog

• Enlaces cortos con dominio propio: DNS, TLS y lo que se ejecuta en el edge
• Configura enlaces cortos de marca: elige un dominio y publica en una tarde
• Cómo bajar el p95 de las redirecciones de 15 ms
• Elido vs Rebrandly
• ¿Los acortadores de URL perjudican el SEO?