Qué es un certificado Wildcard

Definición

Un certificado wildcard (certificado comodín) es un certificado TLS/SSL que cubre todos los subdominios de primer nivel de un dominio, usando un único carácter comodín * en el Common Name (CN) o en el Subject Alternative Name (SAN).

Ejemplo: un certificado emitido para *.ejemplo.com es válido para:

ejemplo.com (en muchos emisores, el dominio raíz también debe incluirse explícitamente)
www.ejemplo.com
api.ejemplo.com
app.ejemplo.com
cualquier-cosa.ejemplo.com

No cubre:

sub.sub.ejemplo.com (solo un nivel de wildcard)
otro-dominio.com

Sintaxis y estándar

El wildcard se representa con el asterisco * en la etiqueta más a la izquierda del nombre DNS (RFC 6125, RFC 2818). La CA emite el certificado para un FQDN como:

*.ejemplo.com

En certificados modernos, los nombres se listan en Subject Alternative Names (SAN). Un certificado wildcard típico puede tener:

*.ejemplo.com
ejemplo.com (dominio raíz, si la CA lo incluye)

El CN legacy puede contener *.ejemplo.com, pero navegadores y bibliotecas usan SAN para validación. Sin el dominio raíz en SAN, https://ejemplo.com puede no considerarse cubierto por el wildcard en algunas implementaciones.

Cuándo usar

Escenario	Motivo
Múltiples subdominios	Un solo certificado para `api`, `app`, `admin`, `staging`, etc., sin emitir un cert por subdominio.
Subdominios dinámicos	Ej.: SaaS donde cada cliente tiene `cliente.tudominio.com`; un wildcard cubre todos.
Entornos (dev/staging)	`dev.empresa.com`, `staging.empresa.com` con el mismo cert.
CDN / multi-origen	Varios hostnames bajo el mismo dominio apuntando a la misma infra.

Reduce el coste operativo (menos certificados que renovar) y simplifica el despliegue cuando hay muchos hostnames.

Limitaciones técnicas

Solo un nivel
*.ejemplo.com cubre a.ejemplo.com, no a.b.ejemplo.com. Para eso hace falta un certificado multi-SAN u otro wildcard para *.b.ejemplo.com.
No cubre el raíz por defecto
Muchas CAs exigen incluir explícitamente ejemplo.com (sin wildcard) en la solicitud; si no, https://ejemplo.com puede fallar en la validación.
Validación del dominio
Para wildcard, la CA suele exigir validación DNS: creas un registro TXT (o CNAME) en el dominio para probar el control. La validación por archivo HTTP no funciona para *, porque la CA no sabe en qué URL colocar el archivo.
EV (Extended Validation)
Los certificados EV wildcard existen pero son raros y caros; la mayoría de wildcards son OV (Organization Validation) o DV (Domain Validation).

Seguridad y riesgos

Compromiso: Si la clave privada del wildcard se filtra, todos los subdominios cubiertos quedan comprometidos. Por eso:
- Guardar la clave en HSM o bóveda (ej.: AWS ACM, HashiCorp Vault).
- Restringir el acceso a la clave y la rotación.
Renovación: Los wildcards suelen tener validez de hasta 1 año (política de las CAs). Automatizar la renovación (ej.: certbot, ACM, Let’s Encrypt) para evitar la expiración.
Auditoría: Saber dónde está instalado el wildcard es más difícil que con certs por hostname; mantener un inventario.

Ejemplo práctico: Let’s Encrypt wildcard

Con certbot y validación DNS (plugin de tu proveedor DNS):

# Validación DNS (obligatoria para wildcard)
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.ejemplo.com" \
  -d "ejemplo.com"

Recibes un desafío TXT para crear en _acme-challenge.ejemplo.com. Tras la validación de la CA, el certificado se emite para *.ejemplo.com y (si se solicitó) ejemplo.com.

Resumen

Aspecto	Detalle
Qué es	Certificado TLS que cubre todos los subdominios de un nivel (`*.dominio.com`).
Ventaja	Un cert para muchos hostnames; útil en SaaS, APIs, entornos.
Limitación	Solo un nivel de wildcard; validación vía DNS; cuidado con la fuga de la clave.
Práctica	Incluir el dominio raíz en SAN cuando haga falta; automatizar renovación y proteger la clave privada.

Usar wildcard es una decisión de operación y riesgo: facilita la gestión, pero exige controles fuertes sobre dónde se usa la clave y cómo se almacena.