Comprender los certificados SSL Wildcard

Qué es un certificado SSL wildcard

Un certificado SSL/TLS vincula una clave pública a uno o varios nombres de host para que los navegadores puedan comprobar que se comunican con el servidor correcto y cifrar la conexión. Un certificado estándar enumera nombres concretos, como example.com y www.example.com. Un certificado wildcard (o comodín), en cambio, contiene un nombre con un asterisco en la posición situada más a la izquierda, como *.example.com, que coincide con cualquier etiqueta única en esa posición.

Esa sola entrada cubre shop.example.com, blog.example.com, api.example.com y cualquier otro subdominio de primer nivel que crees más adelante, sin volver a emitir el certificado. Para las organizaciones que añaden subdominios con frecuencia, esto puede ahorrar mucho trabajo de gestión de certificados.

Qué cubre y qué no cubre un wildcard

La coincidencia de los comodines sigue reglas estrictas definidas en los estándares de TLS y de certificados. El asterisco sustituye exactamente a una etiqueta y solo en la posición situada más a la izquierda.

En la práctica, la mayoría de las autoridades de certificación incluyen automáticamente el dominio raíz junto al wildcard o permiten solicitar ambos nombres a la vez. Al hacer el pedido, confirma que el certificado incluye tanto example.com como *.example.com.

Niveles de validación disponibles

Los wildcard pueden emitirse como certificados validados por dominio (DV), que demuestran el control del dominio, o validados por organización (OV), que además verifican la entidad legal. Las normas del sector no permiten wildcard con validación extendida (EV), así que si necesitas EV para un host concreto, debe figurar de forma explícita.

Wildcard frente a certificados multidominio (SAN)

La principal alternativa es un certificado multidominio, que enumera varios nombres concretos en su campo Subject Alternative Name (SAN). Los dos enfoques resuelven problemas distintos y pueden combinarse en un mismo certificado.

Un efecto secundario útil de los wildcard es la privacidad: los registros de transparencia de certificados publican todos los nombres de cada certificado de confianza pública. Un certificado SAN revela cada nombre de host interno, mientras que un wildcard solo muestra el patrón. No es una medida de seguridad por sí sola, pero reduce la parte de tu infraestructura que aparece listada públicamente.

Cómo obtener un certificado wildcard

Las autoridades de certificación comerciales venden certificados wildcard, y las autoridades basadas en ACME, como Let’s Encrypt, los emiten gratis. En ambos casos generas una clave privada y una solicitud de firma de certificado (CSR), demuestras el control del dominio e instalas el certificado emitido.

Validación DNS-01

Para nombres wildcard, las autoridades ACME exigen el desafío DNS-01. Demuestras el control publicando un registro TXT en _acme-challenge.example.com con un token que facilita la autoridad. La validación por HTTP no se acepta para wildcard, porque servir un archivo en un host no demuestra el control de todos los subdominios posibles.

Con Certbot, una solicitud manual tiene este aspecto:

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

La validación DNS manual no se renueva automáticamente. Para una renovación sin intervención, usa un plugin de DNS o un cliente ACME compatible con la API de tu proveedor de DNS, de modo que el cliente pueda crear y eliminar el registro TXT por sí mismo. Puedes confirmar que el registro es visible antes de validar:

dig +short TXT _acme-challenge.example.com

Si usas registros CAA para restringir qué autoridades pueden emitir certificados para tu dominio, ten en cuenta que la emisión de wildcard puede controlarse por separado con la propiedad issuewild. Nuestra guía sobre cómo configurar correctamente los registros CAA explica la sintaxis.

SSL wildcard para tiendas online

Las tiendas online suelen repartir su plataforma en subdominios: la tienda en www, el área de clientes en account, el pago en checkout o pay, el centro de ayuda en help, los recursos estáticos en cdn y las tiendas regionales en uk o de. Un certificado wildcard puede cubrirlos todos con un solo pedido y una sola fecha de renovación, lo que aporta varias ventajas prácticas:

• Lanzamientos más rápidos. Las nuevas páginas de campaña, tiendas regionales o entornos de pruebas tienen HTTPS válido desde el primer momento.
• Menos huecos. Un subdominio olvidado sin HTTPS provoca avisos en el navegador que pueden dañar la confianza en el peor momento.
• Administración más sencilla. Un solo certificado que vigilar en lugar de muchos con fechas de caducidad distintas.

Estas ventajas deben sopesarse con los riesgos. Las páginas de pago son la parte más sensible de una tienda, y marcos de cumplimiento como PCI DSS esperan una protección sólida de las claves y una segmentación de red clara. Por eso muchos equipos usan un certificado dedicado para los hosts de pago y un wildcard para los subdominios de marketing, contenidos y recursos. Habla del diseño adecuado con quien se encargue de tu evaluación de cumplimiento; esto es información general, no asesoramiento legal ni de cumplimiento.

Riesgos de seguridad y buenas prácticas

El mayor riesgo de un wildcard es que una sola clave privada protege todos los subdominios que coinciden. Si la clave se filtra desde cualquier servidor que la tenga, un atacante podría suplantar cualquier subdominio hasta que el certificado se revoque y se sustituya. Reduce ese riesgo con estos hábitos:

1. Limita su despliegue. Instala el wildcard solo en servidores que controlas y mantienes, no en sistemas de terceros ni heredados.
2. Prioriza los puntos de terminación. Termina TLS en un balanceador de carga o proxy inverso para que menos máquinas tengan la clave.
3. Protege la clave. Restringe los permisos de archivo, no envíes claves por correo y usa un gestor de secretos o un módulo de hardware cuando sea posible.
4. Usa certificados separados para los hosts de alto riesgo. Los puntos de pago, administración y autenticación se benefician de tener sus propias claves.
5. Ten un plan de revocación. Debes saber cómo revocar y reemitir rápidamente si un servidor se ve comprometido.
6. Vigila la toma de control de subdominios. Elimina los registros DNS de servicios que ya no usas, porque un wildcard válido hace que un subdominio secuestrado parezca totalmente fiable.

Duración de los certificados y control de renovaciones

La validez de los certificados de confianza pública es cada vez más corta. Según el calendario del CA/Browser Forum, la validez máxima bajó de 398 a 200 días en marzo de 2026, con nuevas reducciones previstas a 100 días en 2027 y a 47 días en 2029. Los certificados ACME gratuitos ya son de corta duración y están pensados para renovarse automáticamente. Consulta la política vigente de tu autoridad de certificación, ya que las fechas y prácticas exactas pueden ajustarse.

La menor duración hace imprescindible la automatización, pero la automatización también falla: caducan las credenciales de la API de DNS, se migra un servidor y no se copia la tarea de renovación, o simplemente se olvida un wildcard emitido manualmente. Como un wildcard suele proteger muchos servicios a la vez, una renovación olvidada puede tumbar una plataforma entera y no solo un sitio. Comprueba el certificado actual de cualquier host con:

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName

TLDix puede controlar las fechas de caducidad de los certificados SSL junto con dominios y planes de hosting, y enviarte alertas antes de que venzan. Añade tus hosts en el panel de TLDix y consulta nuestras buenas prácticas de seguridad de dominios para protecciones relacionadas.

Instalar y probar un certificado wildcard

Una vez emitido, un wildcard se instala como cualquier otro certificado: sube el certificado, la cadena intermedia y la clave privada a tu servidor web, balanceador de carga o panel de hosting. La falta de certificados intermedios es una causa frecuente de errores en algunos dispositivos, así que instala siempre la cadena completa que proporciona la autoridad de certificación. Tras la instalación, prueba varios subdominios y no solo uno, porque cada host virtual puede apuntar a un archivo de certificado distinto. Comprueba que las peticiones HTTP redirigen a HTTPS, que los nombres y la fecha de caducidad del certificado son correctos y que las versiones antiguas del protocolo están desactivadas según las recomendaciones de seguridad actuales de tu servidor.

Mantén un inventario de dónde está instalado

Anota en una lista cada servidor, balanceador, CDN o servicio en el que hayas instalado el wildcard. Cuando llegue la renovación o tengas que revocarlo, esa lista te dirá exactamente dónde sustituirlo, y evitarás que un sistema olvidado siga sirviendo un certificado caducado o una clave comprometida.

¿Te conviene un wildcard?

Un certificado wildcard es una buena opción cuando gestionas muchos subdominios bajo un mismo dominio, creas otros nuevos con frecuencia y puedes mantener la clave privada en pocos sistemas bien gestionados. Un certificado SAN o certificados individuales suelen ser mejores cuando sirves varios dominios distintos, necesitas EV para un host concreto o quieres aislar servicios sensibles. Muchas organizaciones acaban usando una combinación: wildcard para los subdominios generales, certificados dedicados para los puntos críticos y renovación automática con monitorización independiente de la caducidad para todos ellos.