--- title: "Let’s Encrypt habilita HTTPS para direcciones IP y acelera la era de los certificados “cortos”" description: "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 usua..." url: https://revistacloud.com/lets-encrypt-habilita-https-para-direcciones-ip-y-acelera-la-era-de-los-certificados-cortos/ date: 2026-01-18 modified: 2026-01-18 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2026/01/https-ip-lets-encrypt.jpg categories: ["Guías y recursos", "Seguridad"] tags: ["certificados digitales", "Let's encrypt", "SSL"] type: post lang: es --- # Let’s Encrypt habilita HTTPS para direcciones IP y acelera la era de los certificados “cortos” 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. 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/)