Crear certificado comodín Let's Encrypt

Un Certificado comodín Let’s Encrypt es útil si es necesario proteger varios subdominios con un certificado común, por ejemplo app.example.com, vpn.example.com y portal.example.com. Esto puede resultar útil para Sophos ZTNA, servidores proxy inversos, entornos de prueba o múltiples servicios web internos.

Lo importante es la expectativa: los certificados de Let’s Encrypt son de corta duración. La ventaja no está en el largo plazo, sino en la libre emisión y la automatización. Si el certificado se crea manualmente mediante una entrada DNS TXT, la renovación posterior debe planificarse conscientemente.

Si el certificado se va a crear directamente en Sophos Firewall para WAF, WebAdmin o portales, el método del firewall integrado suele ser mejor: Configurar certificados Let’s Encrypt de Sophos Firewall. Este artículo describe la ruta comodín externa con Certbot.

Cuando un certificado comodín tiene sentido

Un certificado comodín cubre un nivel por debajo de un dominio. Entonces *.example.com se ajusta a portal.example.com, pero no automáticamente a example.com en sí y tampoco a a.b.example.com.

• Muchos subdominios bajo la misma zona: El certificado comodín puede simplificar la administración.
• Un único servicio público: El certificado FQDN único suele ser más limpio.
• El certificado debe usarse en múltiples sistemas: El certificado comodín puede ser práctico, pero controla estrictamente la distribución de claves.
• Se requiere renovación completamente automática: Programe el proveedor de DNS con el complemento Certbot u otro cliente ACME.
• Sophos Firewall solo está diseñado para proteger WAF/WebAdmin/Portales: Cortafuegos incorporado Comprobación Let’s Encrypt.

Un certificado comodín no es una ganancia de seguridad en sí mismo. De hecho, si la misma clave privada está en varios sistemas, el impacto de la pérdida de una clave aumenta. Por lo tanto, se debe documentar dónde se importó el certificado y quién administra la clave privada.

Requisitos

Para un certificado comodín necesita:

• tu propio dominio o zona de subdominio
• Acceso a registros DNS TXT del dominio.
• un servidor Linux o una computadora de administración con Certbot
• Permiso para ejecutar Certbot con privilegios de root
• un plan de renovación, importación y almacenamiento de claves
• Acceso al sistema de destino, por ejemplo Sophos Central ZTNA, proxy inverso o firewall

Los certificados comodín se validan mediante el DNS-01 Challenge. Se establece un registro TXT en _acme-challenge.example.com. Let’s Encrypt comprueba esta entrada DNS y luego emite el certificado. Let’s Encrypt describe los tipos de desafíos básicos en la Documentación de tipos de desafíos.

Instalar Certbot

La Página del proyecto Certbot recomienda la instalación a través de Snap para muchos entornos Linux. En un sistema Linux adecuado, el proceso básico tiene este aspecto:

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

Si Certbot ya se instaló a través de apt, dnf u otro paquete, debe verificar de antemano qué Certbot se está utilizando realmente. De lo contrario, múltiples rutas de instalación paralelas conducirán rápidamente a versiones incorrectas o trabajos de renovación inesperados.

Crear certificado comodín manualmente

Para la validación manual de DNS, Certbot se puede iniciar con --manual y --preferred-challenges dns. En el ejemplo, el certificado debe aplicarse tanto a example.com como a *.example.com:

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

Certbot muestra entonces uno o varios valores TXT. Si example.com y *.example.com se solicitan al mismo tiempo, Certbot crea dos desafíos DNS-01 separados. Ambos valores TXT deben añadirse como registros TXT separados bajo _acme-challenge.example.com. Por tanto, añada el segundo registro además del primero y no lo sobrescriba.

Solo cuando todas las entradas DNS sean visibles en todo el mundo se debe confirmar en Certbot y continuar con la validación.

Comprobación práctica:

dig TXT _acme-challenge.example.com @1.1.1.1

• ciertamente: Solicitar o renovar un certificado sin instalarlo.
• --manual: El valor DNS se establece manualmente.
• --preferred-challenges dns: Utilice el desafío DNS-01.
• -d example.com: Agregar dominio raíz adicional.
• -d '*.example.com': Incluir dominio comodín.

El dominio raíz y el dominio comodín son nombres separados. Si solo se solicita *.example.com, example.com en sí no se incluye automáticamente. Si se solicitan ambos nombres al mismo tiempo, pueden ser necesarios varios registros TXT con el mismo nombre. Esto está permitido en DNS y es exactamente el punto en el que las validaciones suelen fallar, porque se sustituye accidentalmente un valor TXT existente.

Buscar archivos de certificados

Después de una emisión exitosa, los archivos generalmente se encuentran en:

/etc/letsencrypt/live/example.com/

Archivos importantes:

• fullchain.pem: Certificado que incluye certificados intermedios.
• cert.pem: sólo el certificado del servidor.
• privkey.pem: clave privada.
• chain.pem: Certificados intermedios.

Muchos sistemas de destino requieren fullchain.pem y privkey.pem. Algunas máscaras de importación requieren el certificado y la clave por separado, otras también requieren la cadena. Antes de importar, debe quedar claro qué formato espera el sistema de destino.

⚠️ privkey.pem es la clave privada. Este archivo no debe terminar en tickets, chats, correos electrónicos o almacenamiento inseguro. Cualquiera que tenga la clave privada puede hacer un mal uso del certificado.

Renovación del plan

El método manual --manual es sencillo para pruebas y acciones individuales, pero sólo es parcialmente adecuado para certificados productivos. Sin automatización, se debe establecer un nuevo registro DNS TXT cada vez que se renueva.

Hay tres variantes limpias para uso productivo:

• Complemento DNS para el proveedor de DNS: si a Certbot se le permite establecer registros DNS a través de API.
• otro cliente ACME con automatización DNS: si el proveedor o plataforma tiene mejor soporte.
• renovación manual con calendario y propietario: sólo para pruebas o certificados poco utilizados.

Cuando se utiliza el acceso a la API de DNS, las credenciales de la API son particularmente críticas. A un token DNS solo se le debe permitir cambiar la zona necesaria y, si es posible, solo los tipos de registros necesarios. El acceso de administrador de dominio amplio no debe estar desprotegido en un servidor web.

Una prueba de renovación generalmente se verifica con Certbot de esta manera:

sudo certbot renew --dry-run

Para los certificados DNS creados manualmente, esta prueba solo es significativa si el proceso DNS también está automatizado o los enlaces manuales funcionan correctamente.

Importar a entornos de Sophos

Si el certificado se utiliza para Sophos ZTNA, un firewall, un proxy inverso u otro sistema relacionado con Sophos, debe comprobar estos puntos antes de importar:

• ¿El nombre del certificado coincide con el nombre de host público?
• ¿Se requiere el dominio raíz además del comodín?
• ¿El sistema de destino espera fullchain.pem o componentes de certificado separados?
• ¿Se acepta la clave privada o es necesario convertirla a otro formato?
• ¿Existe un proceso documentado para la próxima renovación?
• ¿Está claro en qué sistemas se importó el mismo certificado?

Cuando se trata solo de WAF, WebAdmin o portales en Sophos Firewall, el proceso del firewall integrado suele ser más sencillo porque la creación y renovación se realizan directamente en el firewall. Sin embargo, la ruta externa Certbot o ACME sigue siendo relevante para los certificados comodín reales.

Errores típicos

• La validación falla: Registro TXT aún no visible, nombre de zona DNS incorrecto o uno de varios valores TXT fue sobrescrito. dig TXT _acme-challenge.example.com @1.1.1.1 comprobar.
• El certificado no se aplica a example.com: sólo *.example.com solicitado. Agregue el dominio raíz adicionalmente con -d example.com.
• El certificado no se aplica a a.b.example.com: El comodín solo cubre un nivel de subdominio. planifique su propio certificado o comodín adecuado para una zona más profunda.
• La renovación no funciona automáticamente: forma DNS manual sin automatización. Verifique el complemento DNS u otro cliente ACME.
• La importación falla: archivo o formato incorrecto. fullchain.pem, cert.pem, privkey.pem y comparar solicitud de cadena.
• Riesgo de seguridad debido a copias de claves: clave privada está en múltiples sistemas. Ubicaciones de almacenamiento, acceso e importación de documentos.

Lista de verificación

• Conjunto de niveles de dominio y subdominio.
• Dominio raíz y comodín seleccionados deliberadamente.
• Acceso DNS y permiso de registro TXT disponibles.
• Certbot instalado limpiamente.
• Desafío DNS-01 verificado exitosamente.
• Archivos de certificado y clave privada almacenados de forma segura.
• Se conocen el sistema de destino y el formato de importación requerido.
• Renovación programada con Propietario, Calendario o automatización DNS.
• Los certificados y claves antiguos se eliminan de forma controlada después de una conversión exitosa.

Preguntas frecuentes