Durante años, el cifrado web se ha apoyado en una regla tácita: si un servicio quiere HTTPS, necesita un nombre de dominio. Tiene lógica (las personas navegan por nombres, no por números), pero también es una herencia técnica del ecosistema TLS, donde la validación se diseñó pensando en DNS.
Esa regla empieza a romperse. Desde el 15 de enero de 2026, Let’s Encrypt ofrece disponibilidad general de certificados TLS para direcciones IP (IPv4 e IPv6), con una particularidad clave: caducan a las 160 horas, es decir, algo más de seis días.
Certificados TLS para IP: qué son y por qué cambian el juego
Un certificado TLS “clásico” valida que el servidor al que se conecta el cliente es legítimo para un nombre (FQDN), usando el campo SAN (Subject Alternative Name). La novedad es que ahora el identificador que se valida puede ser directamente una dirección IP.
En la práctica, esto elimina un problema habitual en administración de sistemas: acceder por IP a un servicio HTTPS (paneles temporales, consolas de administración, endpoints de prueba, servicios de infraestructura) sin caer en certificados autofirmados, avisos del navegador o excepciones de seguridad que se eternizan.
160 horas de validez: la condición que lo hace viable (y más seguro)
Let’s Encrypt ha vinculado los certificados de IP a un modelo de vida ultracorta: 160 horas. La lógica es directa: las IP son más “transitorias” que los dominios (reasignaciones, cambios de proveedor, despliegues efímeros), y un certificado “largo” asociado a una IP que ya no controlas sería un riesgo innecesario.
Además, este enfoque encaja con una tendencia más amplia: reducir la “ventana de exposición” si una clave privada se filtra o se compromete. En su anuncio, Let’s Encrypt insiste en que la revocación histórica es imperfecta, y que la caducidad rápida reduce la dependencia de esos mecanismos.
ACME Profiles: la pieza que obliga a automatizar (de verdad)
La emisión de estos certificados se apoya en perfiles (ACME Profiles). Para obtener un certificado de vida corta hay que seleccionar explícitamente el perfil shortlived en el cliente ACME.
Esto tiene dos implicaciones prácticas:
- No todos los clientes ACME lo soportan todavía.
- La operativa manual deja de ser una opción realista: con certificados de ~6 días, el proceso debe ser 100 % automático.
Let’s Encrypt, además, deja claro que los certificados de vida corta son opt-in y que no planean convertirlos en el valor por defecto “por ahora”; pero sí confirman su hoja de ruta para reducir validez estándar de 90 a 45 días durante los próximos años.
Validación: por qué DNS-01 no aplica y qué métodos quedan
En certificados por IP hay una limitación lógica: no puedes demostrar control de una IP mediante DNS, porque DNS no es el identificador primario del certificado.
Por eso, Let’s Encrypt restringe la validación a:
- http-01
- tls-alpn-01
Y deja fuera dns-01. Además, no existe un mecanismo equivalente para comprobar CAA en IPs (CAA se define por dominio).
Casos de uso donde sí encaja (y donde no)
La clave es entender que esto no sustituye a los certificados por dominio: amplía el abanico para escenarios donde DNS es un estorbo o directamente no existe.
Encaja especialmente bien en:
- Homelabs y laboratorios con servicios expuestos puntualmente.
- Entornos de pruebas y front-ends temporales.
- Consolas de administración o endpoints internos con exposición controlada.
- Servicios de infraestructura que hablan HTTPS como transporte (por ejemplo, ciertos despliegues de DoH u otros endpoints técnicos donde el cliente valida por IP).
- Despliegues efímeros en cloud donde se provisionan IPs públicas por tiempo limitado.
Suele ser mala idea en:
- Servicios estables con balanceo, multirregión o cambios de hosting frecuentes (ahí DNS sigue siendo la capa correcta).
- Sistemas donde no puedas garantizar renovación + despliegue automático + monitorización.
Tabla comparativa: certificado “clásico” vs vida corta vs IP
| Tipo de certificado | Identificador | Validez | Cómo se solicita | Cuándo encaja |
|---|---|---|---|---|
| Clásico | Dominio (DNS) | 90 días | Emisión estándar ACME | Web pública, servicios estables |
| Vida corta (dominio) | Dominio (DNS) | 160 horas | Perfil shortlived | Operaciones con rotación agresiva y automatización madura |
| Vida corta (IP) | IP (IPv4/IPv6) | 160 horas | IP + perfil shortlived | Acceso por IP, infra efímera, homelab, pruebas |
Checklist operativo: lo mínimo para no convertirlo en una fuente de incidencias
Con certificados de 160 horas, la pregunta no es “¿cómo lo emito?”, sino “¿cómo lo opero sin sorpresas?”. En entornos profesionales, el checklist mínimo debería incluir:
- Renovación programada con margen, no “al límite”.
- Despliegue automático del certificado renovado (y recarga controlada del servicio).
- Validación externa (healthcheck) del endpoint HTTPS, no solo logs locales.
- Alertas proactivas si falla la renovación o si el certificado baja de X horas de vida.
- Rollback sencillo al certificado anterior si el despliegue rompe TLS.
- Inventario y caducidad centralizada si hay múltiples endpoints (evitar “islas” de certificados).
En infraestructuras donde se gestionan muchos servicios —y especialmente en escenarios multi-entorno—, esta disciplina se parece más a la rotación de secretos que a la gestión tradicional de certificados.
Un cambio pequeño en apariencia, grande en implicaciones
Que Let’s Encrypt (por volumen, impacto y coste) normalice los certificados por IP manda un mensaje claro: HTTPS deja de ser “algo de dominios” y se convierte aún más en un transporte seguro por defecto, incluso cuando la capa DNS no participa.
Para administradores de sistemas, el beneficio es inmediato: menos excepciones inseguras y más opciones para exponer servicios de forma limpia. Para el ecosistema, el cambio es cultural: el futuro del TLS se parece menos a “instalo un certificado y me olvido” y más a “mi infraestructura rota certificados como un proceso rutinario y monitorizado”.
Preguntas frecuentes
¿Para qué sirve un certificado TLS para una IP si ya puedo usar un dominio dinámico?
Para entornos donde no quieres depender de DNS (o no puedes): laboratorios, pruebas, endpoints efímeros o accesos directos por IP. La ventaja es evitar excepciones de seguridad y certificados autofirmados cuando el cliente llega por IP.
¿Por qué Let’s Encrypt limita estos certificados a 160 horas?
Porque la asignación de IPs puede cambiar con rapidez y un certificado “largo” podría seguir siendo válido cuando el solicitante ya no controla esa IP. El ciclo corto reduce ese riesgo y acorta la ventana de exposición ante claves comprometidas.
¿Qué necesito para emitir certificados de vida corta o por IP con Let’s Encrypt?
Un cliente ACME que soporte selección de perfiles y la capacidad de solicitar el perfil shortlived.
¿Qué método de validación se puede usar con certificados por IP?
Let’s Encrypt restringe la validación a http-01 y tls-alpn-01; dns-01 no aplica para IPs.
