Dos maneras de cubrir más de un nombre. El comodín cubre todo un nivel; el certificado SAN enumera nombres exactos. Con Let's Encrypt cuestan lo mismo de mantener, y la diferencia es operativa.

SAN - una lista de nombres

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com
  • Funciona con validación por HTTP: no hace falta una API de DNS.
  • Un subdominio nuevo obliga a reemitir, que es una sola orden.
  • El certificado publica la lista de nombres, así que cada subdominio que tenga es público.

Comodín - todo un nivel

sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'
  • Cubre cualquier subdominio, incluidos los que aún no existen.
  • Exige validación por DNS, así que la renovación necesita acceso por API a su proveedor de DNS, o una persona presente cada sesenta días.
  • Cubre UN solo nivel: *.example.com no cubre a.b.example.com.
  • No cubre el dominio pelado: enumere también example.com, como arriba.

La diferencia de seguridad que lo decide

Una clave comodín vale para todos los subdominios. Póngala en cinco servidores y que caiga uno solo le da al atacante un certificado para todos, incluido el subdominio de pago. Un certificado SAN por servidor mantiene pequeño ese radio de explosión.

Qué elegir

  • Un puñado de subdominios en un servidor: SAN. Validación más sencilla y renovación más sencilla.
  • Muchos subdominios, o generados por cliente: comodín, con validación por DNS automatizada.
  • Subdominios en servidores distintos: un certificado aparte para cada uno, sean los que sean.
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cf.ini \
  -d example.com -d '*.example.com'
Automatícelo en cualquiera de los dos casos. Un reto DNS manual cada sesenta días es una renovación que acabará por olvidarse: vea los subdominios comodín.