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.

Para un gateway de Sophos ZTNA se requiere un certificado wildcard. Sophos Central puede generar este certificado y, después, administrarlo y renovarlo. Como alternativa, puede crearse con Certbot como se explica en este artículo y cargarse como certificado propio. 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.

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
• para Sophos Central, permiso para crear y modificar en DNS el registro CNAME necesario
• para el método manual con Certbot, permiso para crear y modificar los registros TXT de DNS del dominio
• para el método manual, un servidor Linux o equipo de administración con Certbot
• para el método manual, permiso para ejecutar Certbot con privilegios de root
• un plan de renovación, importación y almacenamiento de claves adecuado al método elegido
• acceso al sistema de destino, como Sophos ZTNA en Sophos Fusion, un reverse proxy o un firewall

Los certificados wildcard se validan mediante el desafío DNS-01. En el método manual con Certbot se crea para ello un registro TXT en _acme-challenge.example.com. En el método administrado mediante Sophos Central, un registro CNAME delega esta comprobación en Sophos. La documentación de Let’s Encrypt sobre tipos de desafíos explica los tipos de desafío básicos.

Para Sophos ZTNA: crear el certificado en Sophos Central

Para un gateway ZTNA, el método administrado en Sophos Central suele ser más sencillo que un proceso manual con Certbot: Sophos genera el certificado de Let’s Encrypt y se encarga después de administrarlo y renovarlo. Para ello hay que conocer el dominio utilizado por el gateway y disponer de acceso a su proveedor DNS.

Si la zona DNS utiliza registros CAA, Let’s Encrypt debe estar autorizado en ellos como entidad de certificación. De lo contrario, Let’s Encrypt no podrá emitir un certificado aunque la validación del dominio sea correcta.

1. En Sophos Central, abrir Mis productos > ZTNA y hacer clic en Configuración.
2. Abrir Dominios y certificados y hacer clic en Añadir dominio. Sophos permite un máximo de 100 dominios. Introducir el dominio con el formato example.com y añadirlo.
3. Sophos genera un valor CNAME para este dominio. Crearlo en el proveedor DNS bajo _acme-challenge.example.com. Sustituir example.com por el dominio propio del gateway.
4. Volver a Dominios y certificados, hacer clic en Validar y confirmar que se ha creado el registro CNAME. De esta forma, Sophos comprueba el control sobre el dominio.
5. Tras una validación correcta, hacer clic en Generar certificado LE, leer y aceptar el Acuerdo de suscripción de Let’s Encrypt e iniciar la generación. Según Sophos, tarda unos 60 segundos; se puede salir de la página durante el proceso.

⚠️ Si ya existe un registro TXT bajo _acme-challenge.example.com, debe eliminarse para usar el registro CNAME empleado por Sophos. Antes hay que comprobar si otra aplicación necesita ese registro TXT. Después, el registro CNAME debe permanecer en DNS.

Para los dominios que ya existen en Sophos Central, el procedimiento depende del estado de validación:

• Ya validado mediante un registro DNS TXT:
  1. En Mis productos > ZTNA > Configuración > Dominios y certificados, hacer clic en Generar certificado LE.
  2. En Añadir CNAME, copiar el registro CNAME y crearlo en el proveedor DNS bajo _acme-challenge.example.com.
  3. Eliminar un registro TXT existente allí solo después de realizar la comprobación de impacto indicada anteriormente.
  4. Confirmar la creación del registro CNAME.
  5. Aceptar el Acuerdo de suscripción de Let’s Encrypt y hacer clic en Continuar.
  6. Completar la generación del certificado y comprobar en Dominios y certificados que el dominio y su registro CNAME se muestran con el nuevo formato.
• Aún no validado: Eliminar el dominio existente, volver a añadirlo mediante Añadir dominio, validarlo con Validar y, después, generar de nuevo el certificado de Let’s Encrypt mediante Generar certificado LE.

Sophos solo genera un certificado de Let’s Encrypt por cuenta de Central. Contiene todos los dominios validados. Si se valida otro dominio más adelante, hay que volver a generar el certificado para incluirlo.

Para vincular el certificado con un gateway existente, abrir Mis productos > ZTNA > Gateways, seleccionar el gateway y establecer la opción Automático (Let’s Encrypt) en Dominio y certificado. Guardar el cambio y comprobar después en el gateway la validez y la fecha de caducidad del certificado. Si la validación o la generación aún no han finalizado correctamente, no cambiar todavía el gateway al certificado nuevo; comprobar primero el registro CNAME en el proveedor DNS autoritativo.

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?

Para Sophos ZTNA, el certificado creado con Certbot se asigna al gateway en Sophos Central: abrir Mis productos > ZTNA > Gateways, hacer clic en el nombre del gateway y seleccionar Cargar certificado propio en Dominio y certificado. Cargar el certificado generado y hacer clic en Guardar. A continuación, comprobar en el gateway la validez y la fecha de caducidad; un certificado próximo a caducar debe renovarse, cargarse de nuevo y volver a comprobarse en el gateway.

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 administrados externamente sigue siendo relevante el método 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.
• Para Sophos Central: acceso DNS y permiso para el registro CNAME necesario disponibles.
• Para el método manual con Certbot: acceso DNS y permiso para registros TXT disponibles.
• Método de emisión mediante Sophos Central o un cliente ACME externo elegido conscientemente.
• Certbot instalado correctamente para el método manual.
• Validación del dominio mediante el CNAME de Sophos o el desafío DNS-01 manual comprobada correctamente.
• Para el método externo, archivos del certificado y clave privada almacenados de forma segura.
• Para el método externo, sistema de destino y formato de importación necesario conocidos.
• Renovación planificada mediante Sophos Central o con un responsable, calendario o automatización DNS.
• Para el método externo, 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