Let's Encrypt se prepara para emitir certificados para direcciones IP

• Let's Encrypt pronto admitirá la emisión de certificados con SAN de direcciones IP, y al principio solo estarán disponibles con un perfil de corta duración (short-lived) que expira en 6 días; durante un tiempo, su operación estará limitada mediante una lista blanca
• Antes del lanzamiento oficial no hay un calendario concreto ni instrucciones para solicitar acceso; por ahora continúan las pruebas internas y la preparación
• En el entorno de staging se publicaron un certificado de ejemplo con una dirección IPv6 y un sitio que lo aplica, y se pidió a la comunidad compartir cualquier anomalía o comentario
• Se detectó un bug en Firefox relacionado con la visualización de SAN de IP (BZ #1973855) y las pruebas continúan
• Las pruebas reales confirmaron que puede haber confusión en casos que mezclan DNS SAN e IP SAN, mostrando que la notación de ciertos TLD y las direcciones IPv6 pueden parecerse

---

Let's Encrypt, Getting ready to issue IP address certificates

Estado de la preparación para admitir SAN de direcciones IP

• Let's Encrypt planea pronto admitir en producción la emisión de certificados que incluyan SAN de direcciones IP
• Esos certificados solo se emitirán bajo un perfil short-lived con validez de 6 días, y durante un tiempo su operación estará restringida mediante una allowlist
• Aún no se ha definido la fecha de lanzamiento oficial ni el método para solicitar inclusión en la allowlist; todavía hace falta más preparación interna

Pruebas y certificados de ejemplo

• En el entorno de staging se publicaron certificados de ejemplo con IP SAN y ejemplos de sitios reales que los aplican (direcciones IPv6)
• Se pidió a los usuarios de la comunidad compartir cualquier anomalía, hallazgo interesante o problema detectado

Casos mixtos de IP SAN y DNS SAN

• Durante las pruebas se demostró la posibilidad de emitir certificados que incluyan al mismo tiempo DNS SAN e IP SAN, así como casos de confusión en su visualización
• La notación de ciertos TLD, como .cafe, y las direcciones IPv6 puede resultar similar, lo que puede generar confusión
• También se confirmó en Firefox un bug relacionado con la visualización de SAN de direcciones IP (BZ #1973855)

Resumen

• El soporte de certificados para direcciones IP de Let's Encrypt se aplicará primero de forma limitada, con lista blanca y certificados de corta duración
• Antes de aplicarlo en servicios reales, se revisarán la estabilidad y la compatibilidad mediante pruebas de varios casos y retroalimentación de la comunidad
• También se están discutiendo problemas de visualización en navegadores por el uso mixto de SAN de nombres DNS y direcciones IP

[GN⁺]

Opinión de Hacker News

• Creo que los certificados para direcciones IP también son útiles.
  Pero creo que si Let’s Encrypt diera soporte a certificados S/MIME, el impacto sería mucho mayor.
  Desde hace años hay una situación casi cómica alrededor del cifrado de correo electrónico.
  Ahora la mayoría de los clientes de correo importantes ya soportan cifrado S/MIME de forma nativa, pero, igual que en la web, para tener una experiencia de usuario fluida hace falta obtener certificados de una CA.
  Ya no quedan CAs que ofrezcan certificados S/MIME confiables, gratuitos y con validez de más de un año.
  Como resultado, los usuarios particulares prácticamente no usan cifrado de correo.
  PGP es demasiado incómodo, así que casi nadie lo usa fuera de los entusiastas técnicos.
  Creo que ya deberíamos cifrar también nuestro correo.
  Por cierto, si la CA genera la clave privada por ti, yo consideraría que ese certificado no es confiable.
  Además, como en S/MIME hay que conservar los certificados antiguos para descifrar correos viejos, los certificados que cambian con frecuencia no son prácticos.

  • Sobre eso de que en S/MIME hace falta el certificado anterior para descifrar correos viejos, la clave de descifrado en sí puede seguir usándose también en certificados nuevos (por ejemplo, con la opción --reuse-key de certbot), así que no necesariamente habría que rotarlos tan seguido.
    Otra cuestión es si ese enfoque sea una buena idea.
    Lo que realmente hace falta, en mi opinión, es automatización de emisión de certificados al estilo ACME.
    Hoy casi no se usa porque el proceso de renovación es incómodo.

  • PGP ahora ya tiene un método llamado WKD (Web Key Directory) enlace que permite aplicar a los correos la red de confianza de TLS.
    Conseguir certificados TLS hoy es mucho más fácil que conseguir certificados S/MIME.
    Puede ayudar que la gestión de identidad la lleve un tercero, pero mucha gente trabaja en empresas donde ese modelo de identidad no encaja bien.
    Si se trata de una empresa, creo que tiene más sentido que la gestión de identidad se haga internamente.
    El reciente incidente de Signalgate 1.0 enlace dejó muchas lecciones justo por ser un fallo de gestión de identidad en cifrado de extremo a extremo.
    Por eso pienso que, si los certificados S/MIME o WKD llegaran a adoptarse como sistemas realmente utilizables, también podrían ser útiles para los gobiernos.

  • En lo personal veo con buenos ojos el cifrado de correo basado en S/MIME, pero siento que su viabilidad es baja.
    A muchos usuarios normales ya les cuesta manejar sus claves privadas, y en la práctica incluso les cuesta administrar bien sus contraseñas de correo.
    Al final terminaría siendo necesario emitir certificados de forma centralizada por dominio, o si no habría usuarios que no lograrían obtenerlos, mientras los ciberdelincuentes empezarían a mandar correos firmados con S/MIME.
    Cuando el uso de passkeys se vuelva algo común y haya un relevo generacional, entonces sí tendría más sentido pedirle a la gente que maneje directamente sus propios pares de claves.

  • Opinión: el cifrado de correo simplemente debería desaparecer.
    Referencia: Stop using encrypted email

  • No conozco bien el cifrado S/MIME y tengo una duda.
    ¿Por qué habría que descifrar correos antiguos con el mismo protocolo?
    Yo personalmente pensaba que los certificados eran para el transporte, y que para el almacenamiento real ya habría cifrado de resguardo del servidor o del host; entonces parecería lógico separar ambas cosas: certificados de corta duración para la transmisión y el método que uno quiera para cifrar el almacenamiento. Me pregunto si se me está escapando algo.

• Me pregunto si todas las entidades que administran direcciones, como ISPs y proveedores de nube, también se van a sumar a esto.
  A veces reciclan IPs muy rápido, incluso en menos de 6 días.
  Entendería que los proveedores cloud pusieran un periodo de enfriamiento antes de reasignar una IP o que consultaran y revocaran certificados asociados a esa IP, pero si no lo hacen entonces recae en el usuario validar el host header, rechazar conexiones basadas en IP que no quiera aceptar, o esperar a que desaparezcan por completo los certificados heredados, lo cual añade complejidad.
  También me pregunto cuántos certificados IP se podrán obtener de cada proveedor de nube y a qué costo.

  • En realidad, creo que este problema no es tan distinto de cómo los proveedores cloud ofrecen dominios personalizados o vanity domains.
    Por ejemplo, en Azure puedes vincular a una VM un DNS como myapp.westus.cloudapp.azure.com, y cualquiera puede conseguir de una CA un certificado para ese dominio referencia.
    En esos casos también puede pasar que, sin ningún periodo de enfriamiento, si la VM desaparece otra persona tome ese dominio de inmediato.

  • Los certificados HTTPS pueden renovarse por 90 días desde un día antes de que expire el dominio, y la CA ni siquiera puede saber el límite de tu tarjeta de pago.
    La mayoría de quienes usarían certificados IP probablemente no son usuarios que descartan la IP y desaparecen enseguida.
    Los casos más útiles serían software heredado muy particular o la necesidad de soporte para ECH (Encrypted Client Hello) o ESNI (Encrypted SNI) sin usar IPs compartidas, como hace Cloudflare.
    En el primer caso, el del software legado, no van a soltar la IP tan fácilmente; en el segundo, el de ECH/ESNI, creo que en la práctica sería difícil lograr acceso al dominio real.

  • Sobre si los ISPs tienen que sumarse, yo lo veo al revés.
    El rol de los ISPs no es asignar IPs de una forma compatible con el estándar TLS, sino que los proveedores de certificados TLS deberían encargarse de esa “verificación de identidad” según cómo el ecosistema vincula identidades como dominios o IPs.
    No está del todo claro cómo lo van a abordar esta vez, pero mi intuición es que Let’s Encrypt va a crear una lista de IPs que se transfieren a largo plazo por ASN (número de sistema autónomo), algo así como una base pública mantenida en conjunto al estilo de Mozilla Public Suffix List, y que solo emitirá certificados para las IPs de esa lista, gestionando además la invalidez del certificado cuando se mueva a otro ASN.
    Espero que también lo compartan con otros emisores ACME.

  • Si quieres saber cuántos certificados IP se podrán sacar y cuánto costarán en distintas nubes, también me pregunto si en el futuro habrá soporte para certificados wildcard.

  • En mi caso, que un certificado IP dure aunque sea un solo día ya me sirve para probar URLs https, así que me parece un cambio muy bienvenido.

• Técnicamente entiendo cómo funcionaría, pero me pregunto cuál sería el caso de uso real previsto.

  • Solo con habilitar soporte para ECH (Encrypted Client Hello) o ESNI (Encrypted SNI) ya tendría muchísimo valor.
    En los primeros tiempos de ESNI, solo grandes proxies HTTPS como Cloudflare podían implementarlo, así que la idea de certificados IP parecía casi un sueño; ahora cualquier servidor puede participar en ESNI/ECH.
    Si los clientes empiezan a asumir que todos los servidores tienen certificados IP e intentan usar ESNI, eso podría ayudar mucho a mejorar la privacidad en todo internet.

  • En varias respuestas ya salieron buenos casos de uso, pero también vale la pena mencionar NTS (Network Time Security).
    Si no puedes obtener un certificado IP, NTS también depende de DNS, así que si DNS se cae ya no hay manera de hacer sincronización horaria autenticada.
    DNSSEC falla al verificarse si no tienes la hora correcta, y si dependes de DNS+NTS no hay forma de recuperarte.
    Si se pudiera distribuir tiempo autenticado usando certificados que incluyan la IP, sin necesitar DNS, eso resolvería ese problema.

  • También podría servir cuando necesitas mantener un certificado válido durante cambios importantes en DNS, por ejemplo para asegurar acceso a dashboards o para que automatizaciones antiguas no se rompan por errores de DNS.
    Otro caso sería montar entornos de prueba de forma inmediata sin depender de DNS, o exponer rápidamente servicios como Cockpit hacia afuera.
    En la práctica se abren muchos usos, limitados solo por la imaginación.

  • También sería una opción interesante para hacer DoTLS “oportunista” (consultas DNS sobre TLS) hacia authdns (servidores DNS autoritativos).
    Un DNS autoritativo podría ofrecer servicio en el puerto de DoTLS con un certificado que incluya la IP pública en el SAN (Subject Alternative Name).
    Hoy ya se puede con hostname, pero como una misma IP pública puede tener muchos nombres distintos, un SAN basado en IP lo vincularía de forma más clara.

  • Creo que es ideal para quienes quieren conectar un proyecto directamente por IP en lugar de usar un hostname, o para usos hobby o desechables donde no quieren registrar un dominio.

• Me pregunto por qué no emiten estos certificados los registros regionales de internet (RIR) o los registros locales (LIR).
  ¿Por qué tendría que verificar un tercero a los registrados en RIR o LIR? ¿Es que los registradores de dominio ya tienen demasiado trabajo?
  No sé si la razón es la misma.

• Siento que esto abre más espacio para abusar de TLS de formas nuevas.
  Antes el problema era emitir certificados para dominios que no poseías; ahora también podría pasar con IPs que no posees.
  Seguro los black hats ya lo estarán comentando felices en Telegram.

  • En realidad, los certificados IP existen desde hace mucho; lo único que cambia es que ahora también los va a ofrecer Let’s Encrypt.

• Me pregunto si esto permitirá acceder por https a la página de administración de routers locales, como 192.168.0.1, sin errores de self-signed.

  • No, aunque quizá algún día sí.
    Las direcciones locales no se asignan de forma universal ni se enrutan globalmente, así que en esencia no hay forma de verificarlas.
    Pero si un fabricante de routers realmente quisiera hacerlo, entonces en equipos con una IPv4 pública asignada y que no estén detrás de CG-NAT sí sería posible pedir un certificado para esa dirección pública.
    Con IPv6 sería todavía más fácil, porque normalmente sí tiene enrutamiento global.

  • No, y tampoco debería ser así.
    En la práctica basta con usar un proxy, un dominio real y un certificado real, combinados con una función de reescritura DNS.
    Por ejemplo, usando la UI de nginx manager y adguard como DNS.
    Limitas el DNS del router a adguard, reescribes tu dominio hacia el proxy, registras el dominio y sacas un certificado real, y con eso queda resuelto.
    Yo tengo todos mis servicios locales funcionando con https.

  • No se emiten certificados para IPs privadas.
    La misma IP privada puede corresponder cada vez a equipos totalmente distintos en otras redes, así que no se puede garantizar propiedad exclusiva.

  • Es exactamente al revés.
    Si no es una IP pública, no puedes obtener un certificado válido.
    Lo que sí puedes hacer hoy es sacar un certificado de dominio y apuntar ese dominio a 192.168.0.1.

  • Para obtener un certificado, tienes que poseer realmente esa IP, es decir, una IP pública.

• Me pregunto si también sería posible sacar certificados para IPv4 internas (192.168.x.x, 172.16.x.x, 10.x.x.x), o si está bien que los navegadores ignoren esas direcciones; y si no, entonces si al menos podrían emitirse certificados wildcard para redes internas.

  • En el contexto de certificados emitidos por una CA pública, creo que esa pregunta no tiene mucho sentido.
    A diferencia de los dominios, una IP privada como 10.10.10.10 está “poseída” al mismo tiempo por muchísimas personas.
    Para desarrollo interno existen herramientas como mkcert, y para recursos compartidos dentro de una empresa suele ser más simple usar certificados TLS basados en dominio.

  • Si pudieras demostrar que la clave privada del equipo jamás se filtrará, hasta podrías intentarlo con una CA tradicional.
    Pero con certificados para direcciones internas, en cuanto alguien compre el dispositivo y extraiga la clave privada, ya tendrías el problema de la revocación de la clave del certificado.
    Por eso, si se trata de un equipo confiable, lo realista es importar manualmente el certificado para evitar errores, o si hay varios equipos, montar tu propia CA y distribuir certificados.
    Con un servidor ACME de código abierto se puede automatizar la emisión interna igual que con Let’s Encrypt.

  • Otra opción es poner temporalmente el DNS apuntando a un servidor público para emitir el certificado, y luego volver a bajar ese DNS hacia una dirección interna 192.168… y copiar el certificado y la clave.
    Ojo: algunos routers pueden blackholear respuestas DNS que apuntan a direcciones internas, así que conviene probarlo antes.

  • Creo que los navegadores no deberían ignorar las redes privadas.
    En mi caso, una red privada solo significa mi router local, pero para otras personas podría ser una red enorme que abarque medio mundo.

• Me parece interesante que en el certificado de ejemplo no haya campo subject.
  Me pregunto si es porque se solicita por IP y el DNS queda escrito en el SAN.

  • Según el equipo de Let’s Encrypt, a futuro planean usar únicamente subject alternative names en lugar de subject common name.
    Ya lo aplicaron en el perfil de certificados de corta duración de 6 días, aunque todavía no en el perfil “clásico” de 90 días.

• Mencionan en broma que quizá ya es momento de que vuelva a ponerse de moda la vulnerabilidad CVE-2010-3170.

  • Si implementas tú mismo la lógica de validación X.509, podría quedar una vulnerabilidad así; pero para explotarla de verdad haría falta que una CA con fallas emita ese certificado, así que no lo veo muy probable.

• Qué lástima que los certificados para direcciones IP no puedan emitirse mediante el método de DNS challenge.
  Aunque entiendo por qué es así.