¿Se puede incluir una dirección IP como SAN en un certificado SSL?
Una de las consultas que recibimos con cierta frecuencia es si es posible añadir una dirección IP pública como Subject Alternative Name (SAN) al renovar o emitir un certificado SSL, especialmente con proveedores como Sectigo o Namecheap. La respuesta corta es: técnicamente sí, pero en la práctica no está disponible con CAs públicas de confianza.
En este artículo explicamos por qué, y qué alternativas existen.
¿Qué es un SAN y para qué sirve?
El campo Subject Alternative Name (SAN) es una extensión del estándar X.509 que permite que un certificado SSL sea válido para múltiples nombres o identificadores. Por ejemplo, un certificado con *.domain.com como SAN cubrirá todos los subdominios bajo ese dominio.
El estándar permite incluir diferentes tipos de valores como SAN:
- Nombres de dominio DNS (el uso más habitual)
- Direcciones de correo electrónico
- URIs
-
Direcciones IP (mediante el tipo
iPAddress)
Sí, el estándar lo permite. El problema viene al intentar llevarlo a la práctica con una CA pública.
¿Por qué las CAs públicas no emiten certificados con IPs como SAN?
Las Autoridades de Certificación (CAs) públicas de confianza, como Sectigo, DigiCert, Let’s Encrypt o Namecheap, no emiten certificados con direcciones IP públicas en el SAN para sus productos estándar. Esto no es una decisión arbitraria: responde a los Baseline Requirements del CA/Browser Forum, el organismo que regula qué pueden y no pueden hacer las CAs de confianza.
Las razones principales son:
-
Dificultad para validar la propiedad de una IP
Para un nombre de dominio, la CA puede verificar de forma fiable que el solicitante lo controla mediante métodos como un registro DNS, un fichero HTTP en el servidor o un correo a una dirección del dominio. Para una IP pública, demostrar la “propiedad” es mucho más complejo: una IP puede estar asignada a un operador de tránsito, cambiar de titular, estar detrás de un proveedor de hosting, etc.
-
Historial de abuso con IPs privadas
En el pasado se emitieron certificados que incluían IPs de redes privadas (rangos
192.168.x.x,10.x.x.x, etc.), lo que generó graves problemas de seguridad. El CA/Browser Forum prohibió esta práctica en noviembre de 2015 y posteriormente extendió la restricción a las IPs públicas en entornos de certificados de confianza global. -
Adopción generalizada por todas las CAs relevantes
Sectigo, DigiCert, GlobalSign, Let’s Encrypt y prácticamente todas las CAs integradas en los almacenes de confianza de los navegadores y sistemas operativos no ofrecen esta opción en sus productos estándar. Algunas CAs como DigiCert o GlobalSign la han ofrecido bajo condiciones muy específicas y a un coste muy elevado, pero no es un servicio habitual ni accesible.
¿Cómo funciona la validación del certificado en el navegador?
Cuando un navegador o cliente se conecta a un servidor, compara el identificador al que se está conectando (nombre de host o dirección IP) con los valores SAN del certificado presentado:
- Si la conexión es a
www.domain.com, busca ese nombre en los SANs de tipo DNS. - Si la conexión es directamente a
21x.22x.23x.24, busca esa IP en los SANs de tipoiPAddress.
Si no encuentra coincidencia, lanza un error de certificado. Por eso cuando un cliente se conecta por IP directa a un servidor que solo tiene un certificado con nombres de dominio, la conexión falla con un aviso de seguridad.
El certificado no “se activa” por la cadena de confianza basada en el nombre; lo que ocurre es que la validación del identificador falla antes incluso de verificar la firma de la CA.
¿Cuál es la solución correcta al error?
Si las conexiones están fallando porque se realizan directamente por IP en lugar de por nombre, la solución no pasa por modificar el certificado, sino por corregir cómo se realizan esas conexiones. Estas son las alternativas ordenadas de más a menos recomendable:
| Solución | Viabilidad | Notas |
|---|---|---|
| Forzar que las conexiones usen el nombre DNS |
 Óptima |
Resuelve el problema sin tocar el certificado |
| PKI privada (CA interna) con IP como SAN |
Viable |
Requiere instalar la CA raíz en todos los clientes |
| Certificado público con IP (DigiCert, GlobalSign) |
 ️ Muy limitado |
No disponible |
| Sectigo / Namecheap con IP pública como SAN |
 No disponible |
No lo ofrecen en ninguno de sus productos actuales |
Opción recomendada: forzar el uso del nombre DNS
La opción más limpia, segura y sin coste adicional es identificar qué sistema o aplicación está generando conexiones por IP directa y configurarlo para que use el nombre de dominio correspondiente. Esto suele implicar revisar:
- Configuraciones de cliente o aplicación que apunten a la IP en lugar del FQDN.
- Ficheros
hostsque puedan estar sobreescribiendo la resolución DNS. - Scripts o automatizaciones que construyan URLs con la IP hardcodeada.
Opción alternativa: PKI privada
Si por algún motivo técnico es imprescindible conectar por IP y no es posible cambiar el cliente, se puede crear una Autoridad de Certificación privada (por ejemplo con OpenSSL o con herramientas como step-ca) que emita un certificado con la IP como SAN. El inconveniente es que ese certificado no será de confianza por defecto en ningún sistema, por lo que habrá que distribuir e instalar el certificado raíz de la CA privada en todos los equipos o navegadores que deban confiar en él.
Resumen
| Pregunta | Respuesta |
|---|---|
| ¿Permite el estándar X.509 IPs como SAN? |
Sí |
| ¿Lo ofrecen Sectigo o Namecheap? |
No |
| ¿Por qué no? | Restricciones del CA/Browser Forum y problemas de validación |
| ¿Cuál es la solución recomendada? | Forzar el uso del nombre DNS en el cliente |
Si tienes dudas sobre tu caso concreto o necesitas valorar la opción de PKI privada, no dudes en abrir un ticket y lo analizamos contigo.