Crear un certificado wildcard de Let's Encrypt

Un certificado wildcard de Let’s Encrypt resulta útil cuando se quieren proteger varios subdominios con un único certificado, por ejemplo app.example.com, vpn.example.com y portal.example.com. Puede ser práctico para Sophos ZTNA, reverse proxies, entornos de prueba o varios servicios web internos.

Es importante partir de una expectativa correcta: los certificados de Let’s Encrypt tienen una vigencia corta. Su ventaja no reside en una larga duración, sino en la emisión gratuita y la automatización. Si el certificado se crea manualmente mediante un registro TXT de DNS, la renovación posterior debe planificarse de forma consciente.

Si el certificado se va a crear directamente en Sophos Firewall para WAF, WebAdmin o portales, normalmente conviene más el método integrado en el firewall: Configurar certificados de Let’s Encrypt en Sophos Firewall. Este artículo explica el método wildcard externo con Certbot.

Cuándo conviene un certificado wildcard

Un certificado wildcard cubre un nivel por debajo de un dominio. Por tanto, *.example.com cubre portal.example.com, pero no cubre automáticamente example.com ni a.b.example.com.

• Muchos subdominios en la misma zona: Un certificado wildcard puede simplificar la administración.
• Un único servicio público: Un certificado para un FQDN concreto suele ser más claro.
• El certificado se utilizará en varios sistemas: Un certificado wildcard puede ser práctico, pero la distribución de la clave privada debe controlarse estrictamente.
• Se necesita una renovación totalmente automática: Hay que prever un proveedor DNS con plugin para Certbot u otro cliente ACME.
• Sophos Firewall solo debe proteger WAF, WebAdmin o portales: Conviene comprobar el método Let’s Encrypt integrado en el firewall.

Un certificado wildcard no aporta más seguridad por sí solo. Si la misma clave privada se guarda en varios sistemas, aumenta el impacto de una posible pérdida o filtración. Por ello, debe quedar documentado dónde se ha importado el certificado y quién es responsable de la clave privada.

Requisitos

Para obtener un certificado wildcard se necesita:

• un dominio propio o una zona de subdominio delegada
• acceso a los registros TXT de DNS del dominio
• un servidor Linux o equipo de administración con Certbot
• permiso para ejecutar Certbot con privilegios de root
• un plan para la renovación, la importación y el almacenamiento de la clave
• acceso al sistema de destino, como Sophos Central ZTNA, un reverse proxy o un firewall

Los certificados wildcard se validan mediante el desafío DNS-01. Para ello se crea un registro TXT en _acme-challenge.example.com. Let’s Encrypt comprueba este registro DNS y emite después el certificado. La documentación de Let’s Encrypt sobre tipos de desafíos explica los métodos de validación básicos.

Instalar Certbot

La página del proyecto Certbot recomienda la instalación mediante Snap para muchos entornos Linux. En un sistema Linux adecuado, el procedimiento básico es:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Si Certbot ya se instaló mediante apt, dnf u otro gestor de paquetes, primero hay que comprobar qué ejecutable se está utilizando realmente. Varios métodos de instalación en paralelo pueden provocar que se use una versión inesperada o que se ejecuten tareas de renovación distintas de las previstas.

Crear el certificado wildcard manualmente

Para validar DNS de forma manual, se ejecuta Certbot con --manual y --preferred-challenges dns. En este ejemplo, el certificado debe cubrir tanto example.com como *.example.com:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Certbot muestra uno o varios valores TXT. Si se solicitan al mismo tiempo example.com y *.example.com, se generan dos desafíos DNS-01 independientes. Ambos valores deben añadirse como registros TXT separados en _acme-challenge.example.com. El segundo registro se añade sin sobrescribir el primero.

Antes de continuar en Certbot, al menos los servidores DNS autoritativos del dominio y un resolver externo deben devolver los valores TXT esperados. Un único resolver solo ofrece un indicio, ya que los proveedores DNS pueden distribuir los cambios a distinta velocidad según la ubicación.

Comprobación práctica:

dig TXT _acme-challenge.example.com @1.1.1.1

Los servidores DNS autoritativos se pueden localizar con dig NS example.com. Después, el mismo registro TXT se consulta directamente en uno de esos servidores. Tras una validación correcta, se eliminan los valores TXT del desafío que ya no sean necesarios. Los valores antiguos dificultan las comprobaciones posteriores y, si se acumulan muchos, aumentan innecesariamente el tamaño de la respuesta DNS.

• certonly: Solicitar o renovar un certificado sin instalarlo.
• --manual: Establecer manualmente el valor DNS.
• --preferred-challenges dns: Utilizar el desafío DNS-01.
• -d example.com: Incluir el dominio raíz.
• -d '*.example.com': Incluir el dominio wildcard.

El dominio raíz y el dominio wildcard son nombres independientes. Si solo se solicita *.example.com, example.com no queda incluido automáticamente. Cuando se solicitan ambos nombres al mismo tiempo, pueden ser necesarios varios registros TXT con el mismo nombre. DNS lo permite, y muchas validaciones fallan precisamente porque se sobrescribe por error un valor TXT existente.

Localizar los archivos del certificado

Certbot muestra el nombre real del certificado, los dominios incluidos, la fecha de caducidad y las rutas de los archivos con este comando de solo lectura:

sudo certbot certificates

Tras una emisión correcta, los archivos suelen encontrarse en:

/etc/letsencrypt/live/example.com/

Archivos importantes:

• fullchain.pem: Certificado junto con los certificados intermedios.
• cert.pem: Solo el certificado del servidor.
• privkey.pem: Clave privada.
• chain.pem: Certificados intermedios.

Muchos sistemas de destino necesitan fullchain.pem y privkey.pem. Algunos formularios de importación esperan el certificado y la clave por separado, mientras que otros requieren también la cadena. Antes de importar, debe quedar claro qué formato espera el sistema de destino.

⚠️ privkey.pem es la clave privada. No debe acabar en tickets, chats, correos electrónicos ni repositorios sin protección. Quien obtenga la clave privada puede utilizar indebidamente el certificado.

Planificar la renovación

El método manual con --manual es sencillo para pruebas y operaciones puntuales, pero solo resulta parcialmente adecuado para certificados de producción. Sin automatización, en cada renovación hay que establecer un nuevo valor TXT de DNS.

Para producción existen tres opciones razonables:

• Plugin DNS para el proveedor: Adecuado cuando Certbot puede actualizar registros DNS mediante una API.
• Otro cliente ACME con automatización DNS: Adecuado cuando el proveedor o la plataforma disponen de mejor compatibilidad con otro cliente.
• Renovación manual con responsable y recordatorio de calendario: Indicada solo para pruebas o certificados de uso poco frecuente.

Las credenciales de la API DNS son especialmente sensibles. Un token DNS debe limitarse a la zona necesaria y, cuando sea posible, a los tipos de registro requeridos. Las credenciales con permisos amplios de administración del dominio no deben almacenarse sin protección en un servidor web.

La renovación se prueba normalmente con:

sudo certbot renew --dry-run

En certificados creados mediante validación DNS manual, esta prueba solo es significativa si el proceso DNS está automatizado o si los hooks manuales funcionan correctamente.

Una renovación correcta en el sistema Certbot no actualiza automáticamente un certificado importado anteriormente en Sophos Firewall, ZTNA o un reverse proxy. Se necesita una reimportación documentada o un proceso de despliegue probado que se ejecute únicamente después de una renovación correcta. Tras cada despliegue se comprueban los nombres, la cadena y la nueva fecha de caducidad directamente en el sistema de destino.

Importar en entornos Sophos

Antes de importar el certificado en Sophos ZTNA, un firewall, un reverse proxy u otro sistema relacionado con Sophos, conviene comprobar lo siguiente:

• ¿El nombre del certificado coincide con el hostname público?
• ¿Se necesita el dominio raíz además del wildcard?
• ¿El sistema de destino espera fullchain.pem o componentes separados?
• ¿Acepta la clave privada o debe convertirse a otro formato?
• ¿Existe un procedimiento documentado para la próxima renovación?
• ¿Está claro en qué sistemas se ha importado el mismo certificado?

Si el certificado solo se necesita para WAF, WebAdmin o portales en Sophos Firewall, el proceso integrado suele ser más sencillo, ya que la emisión y la renovación se realizan directamente en el firewall. Para certificados wildcard reales sigue siendo relevante el método externo con Certbot o ACME. Importar y asignar certificados en Sophos Firewall explica después cómo comprobar la clave privada, la cadena de CA y la asignación al servicio.

Errores típicos

• La validación falla: El registro TXT todavía no es visible, el nombre de la zona DNS es incorrecto o se ha sobrescrito uno de varios valores TXT. Comprobarlo con dig TXT _acme-challenge.example.com @1.1.1.1.
• El certificado no cubre example.com: Solo se solicitó *.example.com. Añadir el dominio raíz con -d example.com.
• El certificado no cubre a.b.example.com: El wildcard solo cubre un nivel de subdominio. Planificar un certificado independiente o un wildcard adecuado para la zona más profunda.
• La renovación no se ejecuta automáticamente: El método DNS manual no está automatizado. Comprobar si existe un plugin DNS adecuado u otro cliente ACME.
• Certbot renueva el certificado, pero el sistema de destino sigue mostrando el anterior: No se ha ejecutado la reimportación o el proceso de despliegue. Comprobar el número de serie o la fecha de caducidad directamente en el destino.
• La importación falla: El archivo o el formato no es correcto. Comparar los requisitos para fullchain.pem, cert.pem, privkey.pem y la cadena de certificados.
• Las copias de la clave generan un riesgo: La clave privada está almacenada en varios sistemas. Documentar su ubicación, los permisos de acceso y los puntos de importación.

Lista de comprobación

• Dominio y nivel de subdominio necesario definidos.
• Dominio raíz y wildcard seleccionados de forma consciente.
• Acceso DNS y permiso para crear registros TXT disponibles.
• Certbot instalado de forma coherente.
• Desafío DNS-01 validado correctamente.
• Archivos del certificado y clave privada almacenados de forma segura.
• Sistema de destino y formato de importación necesario conocidos.
• Renovación planificada con un responsable, un recordatorio o automatización DNS.
• Reimportación o proceso de despliegue al sistema de destino probado.
• Certificados y claves antiguos retirados de forma controlada después de una migración correcta.

Preguntas frecuentes