Un certificado SSL comodín asegura un dominio y todos sus subdominios con un solo certificado. En lugar de obtener certificados separados para www.example.com, blog.example.com y api.example.com, un solo *.example.com los cubre todos.
Cómo funcionan los comodines
El carácter comodín * coincide con cualquier subdominio de un solo nivel:
| Certificado | Cubre | No cubre |
|---|---|---|
*.example.com | www.example.com, blog.example.com, api.example.com, anything.example.com | example.com (dominio base), sub.blog.example.com (anidado) |
*.example.com + example.com | Todos los subdominios + el dominio base | Subdominios anidados |
*.sub.example.com | a.sub.example.com, b.sub.example.com | sub.example.com, example.com |
Limitación clave: Los comodines solo coinciden con un nivel. *.example.com NO cubre a.b.example.com.
Comodín vs multi-dominio (SAN)
| Comodín | Multi-dominio (SAN) | |
|---|---|---|
| Cubre | Todos los subdominios de un nivel | Dominios listados específicamente |
| Flexibilidad | Cualquier subdominio funciona automáticamente | Debe listar cada dominio explícitamente |
| Nuevos subdominios | Cubiertos al instante | Requiere nuevo certificado |
| Entre dominios | No (un dominio base) | Sí (example.com + other.com) |
| DNS-01 requerido | Sí | No (HTTP-01 o DNS-01) |
Usa comodín cuando: Tienes muchos subdominios o añades nuevos frecuentemente. Usa SAN cuando: Tienes un conjunto pequeño y fijo de dominios/subdominios específicos.
Cuándo usar un certificado comodín
Buenos casos de uso:
- Tienes muchos subdominios (
app.,api.,docs.,blog.,staging., etc.) y no quieres gestionar un certificado separado para cada uno - Añades nuevos subdominios frecuentemente — se cubren automáticamente sin re-emitir
- Entornos de desarrollo/staging donde los nombres de subdominios cambian a menudo
Cuando los comodines no encajan:
- Necesitas cubrir diferentes dominios base (
example.com+example.org) — usa un certificado SAN en su lugar - Necesitas aislamiento por subdominio — si la clave de un subdominio se ve comprometida, el certificado comodín cubre todos los subdominios
- No puedes modificar registros DNS — la emisión de comodín requiere DNS-01, que necesita acceso DNS
Consideraciones de seguridad
Un certificado comodín significa una clave privada protege todos los subdominios. Si la clave se ve comprometida, un atacante puede suplantar cualquier subdominio — no solo uno.
Mitigaciones:
- Restringe el acceso a la clave privada — solo los servidores que la necesiten deben tener el archivo de clave
- Usa certificados de corta duración — la validez de 90 días de Let’s Encrypt limita la ventana de exposición
- Considera certificados separados para subdominios de alta seguridad (por ejemplo,
admin.example.compodría justificar su propio certificado)
Obtener un certificado comodín gratuito
Let’s Encrypt soporta certificados comodín vía el desafío DNS-01 sin costo. La mayoría de los competidores (ZeroSSL, SSL For Free) restringen los comodines a planes de pago.
Con GetHTTPS:
- Ingresa
*.example.com(+example.comsi quieres el dominio base) - Añade el registro TXT de DNS que GetHTTPS proporciona
- Espera la propagación DNS (GetHTTPS pre-verifica esto por ti)
- Verifica y descarga tus archivos de certificado
Guía completa paso a paso de comodín →
Instalar un certificado comodín
Igual que cualquier certificado — el servidor no sabe que es un comodín:
Nginx:
server {
listen 443 ssl http2;
server_name *.example.com example.com;
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
}
Apache:
<VirtualHost *:443>
ServerName example.com
ServerAlias *.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/cert.pem
SSLCertificateKeyFile /etc/ssl/privkey.pem
SSLCertificateChainFile /etc/ssl/chain.pem
</VirtualHost>
Preguntas frecuentes
¿Por qué no puedo usar HTTP-01 para comodines?
HTTP-01 valida un nombre de host específico colocando un archivo en http://hostname/.well-known/acme-challenge/.... Un comodín cubre subdominios infinitos — no hay un servidor único donde colocar el archivo. DNS-01 prueba el control de todo el dominio a través de un registro TXT a nivel de zona.
¿*.example.com cubre example.com?
No. El dominio base es separado. Añade tanto *.example.com como example.com a tu solicitud de certificado. Tanto GetHTTPS como Certbot soportan esto en un solo certificado.
¿Puedo obtener un comodín gratuito de ZeroSSL?
No. ZeroSSL restringe los certificados comodín a planes de pago ($10/mes+). Let’s Encrypt ofrece comodines gratis.
¿Puedo tener múltiples certificados comodín para el mismo dominio?
Sí. No hay límite técnico. Podrías tener *.example.com y *.staging.example.com como certificados separados. El límite de tasa de Let’s Encrypt es 50 certificados por dominio registrado por semana.
¿Un certificado comodín cubre subdominios anidados?
No. *.example.com cubre www.example.com y api.example.com pero NO dev.api.example.com. Para subdominios anidados, necesitas un comodín separado como *.api.example.com.
¿Cómo pruebo si mi certificado comodín funciona para un subdominio específico?
Apunta el DNS del subdominio a tu servidor, luego prueba:
echo | openssl s_client -connect subdomain.example.com:443 -servername subdomain.example.com 2>/dev/null | openssl x509 -noout -subject -dates
El certificado debe mostrar CN=*.example.com o *.example.com en el campo SAN. Si obtienes un error de conexión, el DNS del subdominio no está apuntando al servidor que aloja el certificado comodín.
¿Puedo usar un certificado comodín en múltiples servidores?
Sí. Instala los mismos fullchain.pem y privkey.pem en cada servidor que maneje subdominios. El certificado no sabe en qué servidor está — solo valida el nombre de host.