Durante una década, el cifrado web se ha apoyado en una idea simple: los certificados TLS se emiten para nombres de dominio, no para números. Sin embargo, esa separación entre “lo que escribe el usuario” (un dominio) y “lo que realmente enruta Internet” (una dirección IP) acaba de perder rigidez. Let’s Encrypt ya permite emitir certificados válidos para IPv4 e IPv6, un cambio que abre la puerta a asegurar servicios sin depender de DNS y que, al mismo tiempo, empuja el sector hacia un modelo de confianza más dinámico, basado en automatización y renovaciones frecuentes.
Por qué esto es relevante: cuando el servicio vive “directo” sobre una IP
Let’s Encrypt reconoce que la mayoría de sus suscriptores seguirá utilizando certificados para dominios —es lo normal: los usuarios identifican servicios por nombre, no por IP. Pero también admite que existe una lista de casos donde la IP es el identificador práctico o, directamente, el único disponible. Entre los escenarios que la propia entidad destaca:
- Acceso a un servicio sin dominio, asumiendo una menor comodidad y fiabilidad que con DNS.
- Páginas por defecto de proveedores de hosting, cuando alguien pega una IP en el navegador y hoy se encuentra un aviso de seguridad.
- Servicios de infraestructura, como DNS over HTTPS (DoH), donde un certificado públicamente confiable facilita verificar identidad y endurecer políticas en clientes.
- Acceso remoto a dispositivos domésticos (NAS, IoT) cuando no hay dominio.
- Conexiones efímeras en infraestructuras cloud, como enlaces entre backends o administración temporal de servidores, siempre que exista una IP pública disponible.
En la práctica, esto da una salida “limpia” a laboratorios, entornos temporales, pruebas de concepto o despliegues que, por diseño, no quieren depender de DNS para habilitar HTTPS.
La condición clave: certificados obligatoriamente de muy corta duración
La contrapartida es importante. Let’s Encrypt establece como política que los certificados que incluyan direcciones IP deben ser “short-lived”: una validez de 160 horas (algo más de seis días). Ese límite no es un detalle: obliga a que el ciclo de vida esté automatizado desde el primer día.
Además, la organización ha hecho generalmente disponible (en producción) tanto esta opción de IP como los certificados de 6 días para dominios, consolidando la idea de que el futuro del TLS pasa por renovaciones más rápidas, exposición al riesgo más corta y menos dependencia de “certificados longevos”.
Qué cambia operativamente
Para emitir certificados “short-lived” e IP, el cliente ACME debe soportar ACME Profiles y solicitar el perfil correspondiente (habitualmente, shortlived). En otras palabras: no basta con “tener Certbot”; hay que comprobar que el cliente y su configuración soportan perfiles.
Y hay otra restricción decisiva: no se puede usar DNS-01 para probar control sobre una IP. Let’s Encrypt limita la validación a HTTP-01 y TLS-ALPN-01. Es lógico: DNS demuestra control sobre un nombre, no sobre un número.
El contexto mayor: de 90 a 45 días (y el papel de la automatización)
El movimiento encaja con la dirección estratégica que Let’s Encrypt lleva tiempo anticipando: un mundo con menos validez por defecto. La autoridad certificadora ya ha explicado su plan de avanzar desde la validez estándar actual de 90 días hacia 45 días, en línea con la tendencia de la industria. En su hoja de ruta se cita el horizonte de 2028 para una transición completa, y también iniciativas para facilitar renovaciones automáticas (por ejemplo, mejoras como ARI en el ecosistema ACME).
Dicho de forma simple: si antes la seguridad se basaba en “emitir y olvidarse”, el nuevo modelo apuesta por “emitir, renovar y verificar constantemente”. Los certificados para IP —por su naturaleza cambiante y por el riesgo de reasignación— son el ejemplo más extremo de esa filosofía.
Tabla rápida para entenderlo
| Tipo de certificado | Identificador | Validez típica | Validación soportada | Implicación práctica |
|---|---|---|---|---|
| TLS estándar | Dominio | 90 días | HTTP-01 / DNS-01 / TLS-ALPN-01 (según caso) | Renovación periódica, automatizable |
| TLS futuro (hoja de ruta) | Dominio | 45 días | Igual que estándar (según CA/cliente) | Más automatización, menos riesgo por exposición |
| TLS short-lived | Dominio | 160 horas | Depende de cliente/perfil | Renovación muy frecuente, orientado a automatización madura |
| TLS para IP (Let’s Encrypt) | IPv4/IPv6 | 160 horas (obligatorio) | HTTP-01 / TLS-ALPN-01 | Ideal para homelab/infra; exige automatización y control del endpoint |
(Los perfiles y requisitos dependen del soporte del cliente ACME y de la configuración del perfil solicitado.)
Impacto real: más seguridad, pero menos tolerancia a la improvisación
En términos de seguridad, el argumento es sólido: con certificados muy cortos, si hay una filtración de clave o un error de emisión, la ventana de impacto se reduce drásticamente. Pero en términos operativos, el mensaje también es claro: quien se acerque a esta opción sin automatización —renovación, recarga de servicios, observabilidad del proceso— se va a encontrar con interrupciones evitables.
Aun así, para un sector que está viviendo el auge del autoalojamiento, los homelabs y las infraestructuras efímeras, la jugada es coherente: HTTPS deja de ser “sinónimo de dominio” y pasa a ser “sinónimo de control verificable del endpoint”, aunque ese endpoint sea una IP.
Preguntas frecuentes
¿Para qué sirve un certificado TLS para una dirección IP?
Para habilitar HTTPS cuando se accede a un servicio directamente por IPv4/IPv6 (sin dominio), o cuando se quiere asegurar un endpoint de infraestructura donde el dominio no es práctico.
¿Por qué Let’s Encrypt limita estos certificados a 160 horas?
Porque las IP pueden cambiar o reasignarse con facilidad. Una validez muy corta reduce el riesgo de que un certificado quede “vivo” cuando la IP ya no está bajo tu control y limita el impacto ante fugas de clave.
¿Se puede validar un certificado de IP con DNS-01?
No. Let’s Encrypt indica que para IP solo se admite HTTP-01 y TLS-ALPN-01, ya que DNS-01 prueba control de un dominio, no de una dirección IP.
¿Qué se necesita para que funcione en producción sin sustos?
Un cliente ACME con soporte de ACME Profiles, renovación automatizada (cron/systemd), recarga automática del servicio (Nginx/Apache/HAProxy, etc.) y monitorización de fallos en el proceso de emisión/renovación.
