--- title: "Let’s Encrypt abre la puerta al HTTPS por IP: certificados para IPv4 e IPv6 con caducidad de 160 horas" description: "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é..." url: https://www.stackscale.com/es/blog/lets-encrypt-abre-puerta-https-por-ip/ date: 2026-01-18 modified: 2026-01-18 author: "David Carrero" image: https://www.stackscale.com/wp-content/uploads/2026/01/https-ip-lets-encrypt-stackscale.jpg categories: ["General", "Internet"] tags: ["let's Encrypt", "ssl"] type: post lang: es --- # Let’s Encrypt abre la puerta al HTTPS por IP: certificados para IPv4 e IPv6 con caducidad de 160 horas 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. Fuente: [Let’s Encrypt abre la puerta al HTTPS por IP](https://administraciondesistemas.com/lets-encrypt-abre-la-puerta-al-https-por-ip-certificados-para-ipv4-e-ipv6-con-caducidad-de-160-horas/)