14 puntos por GN⁺ 2026-01-17 | 1 comentarios | Compartir por WhatsApp
  • Let's Encrypt comenzó a ofrecer oficialmente certificados de corta duración con validez de 6 días y certificados basados en direcciones IP
  • Los certificados de corta duración son válidos durante 160 horas (aprox. 6 días y 16 horas) y pueden emitirse seleccionando el perfil shortlived en un cliente ACME
  • Estos certificados fomentan renovaciones más frecuentes para reforzar la seguridad y reducir la dependencia de procedimientos de revocación poco confiables
  • Los certificados para direcciones IP son compatibles tanto con IPv4 como con IPv6 y, debido a la alta variabilidad de las direcciones IP, solo se emiten como certificados de corta duración
  • Esta medida se considera un cambio gradual para ampliar los sistemas automatizados de renovación de certificados y fortalecer la seguridad

Disponibilidad de certificados de corta duración (6 días)

  • Un certificado de corta duración (short-lived certificate) es válido por 160 horas, una vida útil mucho más corta que la de los certificados tradicionales de 90 días
    • Puede emitirse seleccionando el perfil de certificado shortlived en un cliente ACME
  • Este certificado refuerza la seguridad al exigir validaciones más frecuentes y mitigar los problemas de inestabilidad del sistema de revocación
    • Antes, si una clave privada se veía comprometida, era necesario revocar el certificado, pero como el proceso de revocación no era confiable, la vulnerabilidad podía mantenerse hasta el vencimiento
    • Con el uso de certificados de corta duración, ese período de exposición se reduce considerablemente
  • Los certificados de corta duración son opcionales (opt-in) y no hay planes de convertirlos en la opción predeterminada
    • Los usuarios que ya tienen un proceso de renovación automática completamente implementado pueden cambiar fácilmente
    • Sin embargo, considerando que no todos los usuarios están acostumbrados a ciclos de vida tan cortos, se mantendrá la configuración predeterminada actual
  • En los próximos años, se planea reducir la validez predeterminada de los certificados de 90 días a 45 días

Certificados para direcciones IP

  • Un certificado para dirección IP (IP address certificate) permite autenticar conexiones TLS usando una dirección IP en lugar de un nombre de dominio
    • Es compatible con IPv4 y con IPv6
  • Los certificados para direcciones IP deben emitirse únicamente en formato de certificado de corta duración
    • La razón es que las direcciones IP cambian con más frecuencia que los dominios, por lo que requieren validaciones frecuentes
  • Los detalles relacionados y los casos de uso pueden consultarse en la primera publicación sobre certificados IP, anunciada en julio de 2025

Soporte y patrocinio

  • Este desarrollo fue posible gracias al apoyo de Open Technology Fund, Sovereign Tech Agency y patrocinadores y donantes
  • Let's Encrypt es una autoridad certificadora (CA) gratuita, automatizada y abierta operada por la organización sin fines de lucro Internet Security Research Group (ISRG)
  • En el informe anual 2025 de ISRG puede consultarse la actividad general de la organización sin fines de lucro

1 comentarios

 
GN⁺ 2026-01-17
Comentarios en Hacker News
  • Hasta hoy, no se podía obtener un certificado para dirección IP con certbot
    En su lugar usé lego, pero me tomó bastante tiempo encontrar el comando exacto
    El comando que me funcionó ayer fue este
    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

    • También me preguntaba si Caddy ya soporta esta función
      Parece que todavía está en proceso (issue de GitHub)
  • Los certificados para direcciones IP son un tema especialmente interesante para los usuarios de iOS que operan su propio servidor DoH
    En iOS, para que funcione, había que tener certificados correctos tanto para el FQDN como para la IP
    Por eso los perfiles de servicios grandes como dns4eu o nextdns funcionan bien, pero un servidor DoH hecho por uno mismo fallaba

    • OpenSSL exige estrictamente que, al establecer una conexión TLS, la dirección IP esté incluida en el campo SAN del certificado
      Probablemente no fue algo agregado explícitamente por un ingeniero de iOS, sino un efecto secundario de la librería criptográfica que usan
    • Yo uso a diario DoH con mi dominio personal detrás de un reverse proxy y no tengo ningún problema
  • Me preguntaba por qué certificados de 6 días
    Pensé que 8 días sería mejor para renovar por semanas, y además 8 es una potencia de 2 y un número de la suerte
    Pero 6 simplemente no me convence

    • Con un ciclo de 6 días, a largo plazo la carga se distribuye uniformemente entre los días de la semana
      Con 8 días, el tráfico podría concentrarse en ciertos días
    • En realidad no son 6 días sino unas 160 horas (6.6 días)
      160 también es la suma de los primeros 11 números primos y la suma de los cubos de los tres primeros primos
    • 6 días también simbolizan que Dios trabajó 6 días y descansó el séptimo
    • 6 es el número perfecto más pequeño, así que simboliza perfección
  • Ojalá lo siguiente sea enfocarse en emitir certificados para direcciones .onion
    .onion ya tiene un par de claves, así que la prueba de propiedad puede ser más confiable que con DNS

  • Si quieres certificados para IP, certbot todavía no lo soporta
    Hay un PR abierto al respecto (#10495)
    En cambio, parece que acme.sh ya lo soporta

    • Entre los clientes ACME que actualmente soportan direcciones IP están acme.sh, lego, traefik, acmez, caddy, cert-manager
      Espero que certbot también lo soporte pronto
  • Yo estaba probando con un ciclo de renovación de 2 semanas, y ahora me salieron certificados de 6 días, así que me desconcertó
    Si el pipeline falla, hay muy poco tiempo para depurarlo
    Cuesta aceptar la idea de que una IP sea más volátil que un dominio
    La IP fija de un VPS no cambia tan seguido

    • Pero en AWS, por ejemplo, una Elastic IP puede liberarse de inmediato
      Si emites un certificado de 45 días y devuelves la IP enseguida, otro usuario podría empezar a usar esa IP
      Eso significaría tener un certificado válido para la IP de otra persona, lo cual es riesgoso
    • En entornos cloud, las IP se reasignan rápido, así que hasta 6 días parece mucho
    • Una vida útil demasiado corta para los certificados no encaja bien con prácticas operativas realistas
      Este tipo de política parece una aproximación que no conoce bien el trabajo en campo
    • El problema es el control de propiedad sobre la IP
      La mayoría de los operadores de servicios no controla directamente la IP en sí, así que es una medida para reducir el riesgo del CA
    • Si no asocias una EIP a una instancia EC2, al reiniciarla casi siempre recibe otra IP
      Es difícil abusar de eso, pero sigue siendo algo a considerar desde el punto de vista de seguridad
  • Me pregunto si los certificados para IP podrían hacer que el modo transporte de IPsec vuelva a recibir atención
    El RFC 5660 que escribí también está relacionado

    • Pero siendo realistas, SDN o las VPN site-to-site ya están bastante extendidas
      Seguir haciendo que un túnel IPsec use certificados sigue siendo engorroso
      Algunos equipos de firewall incluso tienen bugs extraños que causan fallos de autenticación cuando la cadena de certificados es larga
    • El estándar de IPSec es demasiado grande y complejo, y hasta las empresas que lo crearon siguieron acumulando CVE durante décadas
  • Como los certificados para IP solo son posibles para direcciones accesibles desde Internet, el TLS para dispositivos en LAN sigue siendo difícil

    • Con IPv6 sí se puede, incluso sin exposición externa
      En el edge puedes recibir el tráfico con DNAT, enviarlo a una VM para renovar el certificado y luego distribuirlo al dispositivo interno
    • Yo uso un certificado wildcard (*.home.example.com) para mi red doméstica
      Necesitas un DNS público que permita configurar registros TXT por API, pero el plugin DNS de lego soporta muchos proveedores
    • En estos casos, usar una CA privada también es una opción
    • Como no puedes demostrar desde afuera la propiedad de una dirección interna, creo que simplemente es mejor usar un dominio
  • Esta noticia de verdad me da mucho gusto
    Los certificados para IP ayudan a resolver el problema de bootstrap inicial del software self-hosted
    Por ejemplo, puede que ya no haga falta la función de subdominios instantáneos de TakingNames

  • Los certificados para direcciones IP son útiles cuando servicios efímeros (ephemeral services) necesitan comunicarse con TLS
    Como no hace falta crear registros DNS por separado, resulta conveniente cuando levantas cientos de instancias temporales

    • También se pueden usar con Encrypted Client Hello (ECH)
      Si usas un certificado para IP en lugar de un SNI expuesto en texto plano, desde afuera no se puede ver el nombre real del host
      Esto permitiría que incluso sitios pequeños que no están en una gran nube usen ECH sin proxy
    • En el anuncio oficial de Let's Encrypt hay varios casos de uso resumidos
    • También atrae el hecho de que no hay dependencia de un registrador
      Se gana más anonimato
    • Si el servicio no está orientado a personas, eliminar la dependencia del nameserver resulta especialmente útil
    • También puede aplicarse a protocolos como DNS over TLS o DNS over HTTPS