Certificado SSL Wildcard Let’s Encrypt con validación DNS

Cuando necesitas proteger un dominio principal y todos sus subdominios con un solo certificado, la opción wildcard de Let’s Encrypt es, probablemente, lo más eficiente que hay. Los certificados estándar cubren un único FQDN (un nombre de dominio totalmente cualificado, para entendernos). El wildcard, en cambio, cubre cualquier subdominio de primer nivel gracias al comodín *.tudominio.com. Aquí va una explicación de qué son, cuándo merece la pena usarlos y cómo generarlos con Certbot mediante validación DNS, que es el único método con el que Let’s Encrypt emite este tipo de certificados.

¿Qué es un certificado wildcard y cuándo necesitas uno?

Hablamos de un certificado SSL/TLS cuyo campo Subject Alternative Name incluye un registro con asterisco, del tipo *.redservicio.net. Ese asterisco funciona como comodín: coincide con cualquier subdominio de primer nivel del dominio base. Blog.redservicio.net, tienda.redservicio.net, panel.redservicio.net… todos entran bajo el mismo paraguas.

Conviene conocer sus limitaciones antes de llevarse sorpresas:

• Solo cubre un nivel de subdominio. El certificado para *.tudominio.com sirve para app.tudominio.com, pero no para api.app.tudominio.com. Si necesitas dos niveles, toca pedir otro wildcard específico o añadir el nombre completo al SAN.
• No cubre el dominio raíz. *.tudominio.com no protege tudominio.com. La buena noticia: Let’s Encrypt siempre incluye el dominio raíz junto al wildcard en el mismo certificado.
• Una única clave privada. Si el servidor donde reside el certificado se compromete, quedan expuestos todos los subdominios a la vez. En entornos con varios servidores o proveedores, evalúa bien este riesgo.

¿Cuándo tiene sentido un wildcard? Escenarios típicos: instalaciones WordPress multisitio con subdominios, paneles de administración (panel.tudominio.com), entornos de staging y preproducción (dev.tudominio.com, test.tudominio.com), aplicaciones SaaS con subdominios por cliente… o, simplemente, cuando el número de subdominios crece tanto que mantener un certificado por cada uno se vuelve inviable. Y hay un detalle práctico: Let’s Encrypt limita los certificados no wildcard a 100 nombres por certificado y a 50 certificados por semana por dominio registrado. Un wildcard elimina ambas restricciones de golpe.

Requisitos previos antes de generar el certificado

Antes de lanzar Certbot, revisa que cumples lo siguiente. Ojo con esto: la validación DNS exige control sobre la zona DNS del dominio. Con acceso solo al servidor no basta.

1. Acceso a la gestión DNS del dominio. Necesitas poder crear registros TXT en la zona autoritativa: panel del registrador (Cloudflare, OVH, Gandi, etc.) o acceso al servidor DNS propio (BIND, PowerDNS).
2. Certbot instalado. En Debian/Ubuntu: sudo apt install certbot. En CentOS/RHEL: sudo dnf install certbot. Para validación DNS manual no necesitas ningún plugin de webserver.
3. Certbot 0.22.0 o superior. Las versiones anteriores no soportan la API ACME v2 de Let’s Encrypt, imprescindible para wildcard. Comprueba con certbot –version.
4. Puerto 443 configurado en el servidor web. La validación es por DNS, sí, pero el certificado hay que instalarlo y servirlo. Verifica que el virtual host HTTPS está preparado.
5. Cuenta de correo válida para el registro ACME, necesaria para avisos de expiración y recuperación de cuenta.

Cómo crear un certificado SSL wildcard Let’s Encrypt con Certbot y validación DNS manual

¿Por qué es obligatoria la validación DNS para wildcard? Porque Let’s Encrypt necesita comprobar que controlas todo el dominio, no solo un host concreto. El desafío dns-01 consiste en crear un registro TXT con un token específico. Este método manual es ideal para pruebas, dominios sin API o migraciones puntuales; su inconveniente, eso sí, es que la renovación no puede automatizarse sin intervención humana.

Ejecuta el siguiente comando, sustituyendo tu dominio:

sudo certbot certonly –manual –preferred-challenges dns -d «tudominio.com» -d «*.tudominio.com» –server https://acme-v02.api.letsencrypt.org/directory

Certbot mostrará algo parecido a esto:

Please deploy a DNS TXT record under the name _acme-challenge.tudominio.com with the following value: 9sKqX7fT2mLpB4nRvW8yHc1Zd6GjN3aQeU0tYxA5bCo

Ahora, con cuidado:

1. Crea en tu panel DNS un registro TXT con nombre _acme-challenge.tudominio.com y el valor exacto que indica Certbot.
2. Espera a que el registro se propague. Compruébalo con dig TXT _acme-challenge.tudominio.com +short o con alguna herramienta online de propagación DNS antes de continuar.
3. Pulsa Enter en Certbot para que Let’s Encrypt verifique el registro y emita el certificado.
4. Si emites para varios dominios, repite el proceso: Certbot pedirá un registro TXT distinto por cada uno.

Si todo sale bien, Certbot confirmará la emisión y dejará los archivos en /etc/letsencrypt/live/tudominio.com/: fullchain.pem (certificado completo) y privkey.pem (clave privada). En versiones antiguas puedes usar –manual-public-ip-logging-ok para saltarte la pregunta sobre registro de IP. Ten presente que estos certificados duran 90 días, y con validación manual tendrás que repetir el proceso entero en cada renovación. Si buscas automatización completa, el plugin DNS de tu proveedor es el camino correcto.

Y si prefieres no complicarte con registros DNS, comandos ni renovaciones, en RedServicio (redservicio.net) tienes ayuda profesional para emitir, instalar y automatizar certificados SSL en tu servidor o WordPress.

Automatización con acme.sh y DNS API para renovaciones automáticas

Renovar a mano un wildcard cada 60 o 90 días, ya lo verás, acaba pesando. Un día se te olvida, el sitio da error de certificado, y a correr. La solución pasa por un cliente ACME con soporte de DNS API (acme.sh, por ejemplo), que actualiza el registro TXT solo antes de cada renovación. A diferencia de certbot con el plugin manual —que te obliga a intervenir cada vez—, acme.sh se autentica contra el proveedor DNS mediante credenciales de API y el proceso queda completamente desatendido.

El flujo es sencillo. Primero obtén la clave API de tu proveedor (Cloudflare, OVH, Namecheap, Dinahosting…). Después expórtala como variable de entorno:

• Cloudflare: exporta CF_Token=»tu-token» y CF_Account_ID=»tu-id»
• OVH: exporta OVH_AK, OVH_AS y OVH_CK con los valores de tu aplicación registrada
• Dinahosting: exporta DH_User y DH_Password

Y emite el certificado indicando el alias DNS de tu proveedor. Algo así:

acme.sh –issue –dns dns_cf -d midominio.com -d *.midominio.com

acme.sh se encarga del resto: crea el registro TXT _acme-challenge, espera a que propague, valida y borra el registro al terminar. La renovación se queda programada en cron por su cuenta. Para que el servidor web recargue el certificado nuevo, añade el hook de instalación:

acme.sh –install-cert -d midominio.com –key-file /etc/nginx/ssl/key.pem –fullchain-file /etc/nginx/ssl/cert.pem –reloadcmd «systemctl reload nginx»

Un detalle que no deberías saltarte: guarda esas credenciales API con permisos restrictivos (chmod 600) y, si tu proveedor lo permite, usa tokens limitados a la zona DNS del dominio. Un token comprometido con permisos globales es una puerta abierta a problemas serios.

Instalación del certificado wildcard en Nginx y Apache

Emitido el certificado, configurarlo en el servidor web no difiere en nada de un certificado estándar. La ventaja, eso sí, es que un solo par de archivos te cubre todos los subdominios.

Nginx

En el bloque server de cada virtual host, apunta a los archivos del wildcard:

• ssl_certificate /etc/nginx/ssl/midominio.com/fullchain.pem;
• ssl_certificate_key /etc/nginx/ssl/midominio.com/key.pem;
• ssl_protocols TLSv1.2 TLSv1.3;

Puedes reutilizar el mismo certificado en tantos bloques server como subdominios tengas (app.midominio.com, api.midominio.com…), siempre dentro del mismo server_name.

Apache

En cada VirtualHost del puerto 443 configura:

• SSLCertificateFile /etc/letsencrypt/live/midominio.com/fullchain.pem
• SSLCertificateKeyFile /etc/letsencrypt/live/midominio.com/privkey.pem

Añade también una redirección 301 del puerto 80 al 443 para forzar HTTPS en todo el dominio y sus subdominios. Tras aplicar los cambios, verifica con nginx -t o apachectl configtest y recarga el servicio. El resultado final compruébalo en SSL Labs: con la configuración bien hecha, deberías llevarte una A o incluso una A+.

Conclusión: buenas prácticas para mantener tu wildcard siempre válido

Para un dominio con muchos subdominios, el wildcard de Let’s Encrypt es la opción más razonable: una sola emisión, coste cero y una única fecha de renovación que vigilar. Que no dé sustos a largo plazo depende de cómo lo montes. Algunas recomendaciones:

1. Automatiza desde el primer día con acme.sh o certbot + DNS API. Las renovaciones manuales, tarde o temprano, se olvidan.
2. Verifica la renovación simulándola: acme.sh –renew -d midominio.com –force o certbot renew –dry-run.
3. Configura alertas por correo o por Telegram cuando queden menos de 20 días de validez.
4. Protege las credenciales DNS API y la clave privada con permisos 600 y propiedad root.
5. Ojo con esto: Let’s Encrypt expone los dominios validados en Certificate Transparency. Si necesitas discreción en un subdominio interno, quizá te convenga valorar una CA privada.

Con la validación DNS bien automatizada, el wildcard se renueva solo, los subdominios permanecen en HTTPS y desaparecen de raíz esos errores de certificado que tan mala imagen dan ante los visitantes. Y si en algún momento el proceso se atasca, tu proveedor cambia la API o quieres integrar el wildcard en un entorno WordPress con proxy o CDN, en RedServicio (redservicio.net) tienes soporte técnico especializado para dejarlo todo funcionando de forma permanente.