Saltar al contenido

Dirección IPv6 en certificado SSL

Este grupo redactor ha estado por horas investigando soluciones a tus dudas, te compartimos la soluciones por eso esperamos servirte de gran ayuda.

Solución:

Solución 1:

Sí el subjectAltName la extensión permite una iPAddress OID, que puede contener una dirección IPv6 de 16 octetos en el orden de bytes de la red. Consulte RFC5280 s4.2.1.6 para obtener más detalles.

Solucion 2:

Técnicamente, puede tener una dirección IP (v4 o v6, no importa) en la sección SAN de un certificado X.509, pero no sin precauciones.

Uso de certificados usando direcciones IP

Son raros en el mundo HTTPS (porque derrotan al alojamiento virtual HTTPS masivo), pero existen, https://1.1.1.1/ siendo un caso famoso. Al utilizar las búsquedas de registros de transparencia de certificados, puede encontrar muchos más certificados con direcciones IP en su extensión de nombre alternativo del sujeto, aquí hay un enlace para buscar algunos: https://censys.io/certificates?q=parsed.extensions.subject_alt_name.ip_addresses% 3A * (Tampoco pude encontrar una manera de buscar específicamente direcciones IPv6; https://crt.sh/ también tiene un criterio de búsqueda en Identify / iPAddress pero no pude hacer que eso funcione en absoluto).

De hecho, son necesarios para los nuevos protocolos “DNS sobre HTTP” y “DNS sobre TLS”.

Tenga en cuenta que:

  • para DoT, el certificado no importa tanto como el público subyacente key, ya que el cliente debería haberlo anclado de antemano
  • para DOH hay una discusión sobre el certificado:

Un cliente de DoH puede enfrentar un problema de arranque similar cuando la solicitud HTTP necesita resolver la parte del nombre de host del URI de DNS. Solo
ya que la dirección de un servidor de nombres DNS tradicional no se puede
determinado desde ese mismo servidor, un cliente DoH no puede usar su DoH
servidor para resolver inicialmente el nombre de host del servidor en una dirección.
Las estrategias alternativas que un cliente puede emplear incluyen 1) hacer que el
parte de la resolución inicial de la configuración, 2) URI basados ​​en IP y
correspondientes certificados basados ​​en IP para HTTPS, o 3) resolver el
El nombre de host del servidor de la API de DNS a través de un DNS tradicional u otro servidor DoH
sin dejar de autenticar la conexión resultante a través de HTTPS.

Pero tenga en cuenta que los certificados con direcciones IP funcionan y existían mucho antes de que DoT y DoH se generalizaran, pero en otra área poco conocida: RPKI. Se trata de asegurar los intercambios BGP: cuando alguien anuncia un bloque dado de direcciones IP, a través de su RIR del que obtuvo el bloque de direcciones IP, puede obtener un certificado (por lo tanto firmado por la CA RIR) que contiene tanto sus bloques de direcciones IP como su COMO número. Esto permite a otros verificar que las direcciones IP sean anunciadas por el número de AS correcto. Consulte https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure para obtener una introducción a todo eso.

Estos certificados están normalizados en RFC 6487 y tienen este aspecto:

Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer

   Data:
     Version: 3 (0x2)
     Serial: 1500 (0x5dc)
     Signature Algorithm: SHA256WithRSAEncryption
     Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
     Validity
      Not Before: Oct 25 12:50:00 2008 GMT
       Not After : Jan 31 00:00:00 2010 GMT
     Subject: CN=A91872ED
     Subject Public Key Info:
[...]
     X509v3 extensions:
[...]
      sbgp-autonomousSysNum: critical
          Autonomous System Numbers:
            24021
            38610
            131072
            131074

        sbgp-ipAddrBlock: critical
          IPv4:
            203.133.248.0/22
            203.147.108.0/23

Generando el certificado / CSR

Vea RFC 5280 como dijo womble en su respuesta. Preste especial atención al hecho de que necesita usar un campo “Dirección IP” en el Nombre alternativo del sujeto y no el caso común predeterminado / común de “Nombre DNS” que se aplica solo a los nombres.

Ese RFC atiende correctamente las direcciones IPv4 e IPv6:

Cuando la extensión subjectAltName contiene una iPAddress, la dirección DEBE almacenarse en el octeto string en “orden de bytes de red”, como se especifica en [RFC791]. El bit menos significativo (LSB) de cada octeto es el LSB del byte correspondiente en la dirección de red. Para IP versión 4, como se especifica en [RFC791], el octeto string DEBE contener exactamente cuatro octetos. Para IP versión 6, como se especifica en
[RFC2460], el octeto string DEBE contener exactamente dieciséis octetos.

Si controla la CA, entonces no es un problema firmar el CSR construido apropiadamente. Si desea que lo firme una autoridad competente conocida, deberá encontrar una que acepte hacerlo y, aunque no tengo una lista, creo que existen, pero no son la mayoría.

Validación por una CA “acreditada”

La mayoría de las CA y las reconocidas por los navegadores aplican las pautas de requisitos de CAB Forum. Además de otras cosas, describen qué tipo de validación debe realizar una CA en función del contenido del certificado que se emitirá.

Ver https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf

En tu caso específico:

7.1.4.2.1 Asunto Nombre alternativo ExtensionCertificate Campo: extensiones: subjectAltNameRequired / Optional: RequiredContents: Esta extensión DEBE contener al menos una entrada. Cada entrada DEBE ser un dNSName que contenga el nombre de dominio completo o una iPAddress que contenga la dirección IP de un servidor. La CA DEBE confirmar que el Solicitante controla el Nombre de dominio completo o la dirección IP o que el Registrante del nombre de dominio o el cesionario de la dirección IP le ha otorgado el derecho a usarlo, según corresponda.

La sección 3.2.2.5 detalla cómo se valida una dirección IP, con las siguientes posibilidades (consulte el documento para obtener más detalles):

  • 3.2.2.5.1. Cambio acordado en el sitio web
  • 3.2.2.5.2. Correo electrónico, fax, SMS o correo postal al contacto de la dirección IP
  • 3.2.2.5.3. Búsqueda inversa de direcciones
  • 3.2.2.5.4. Cualquier otro método (que ahora es discutible debido a que “las CA NO DEBERÁN realizar validaciones con este método después del 31 de julio de 2019”).
  • 3.2.2.5.5. Contacto telefónico con contacto de dirección IP
  • 3.2.2.5.6 Método ACME “http-01” para direcciones IP
  • 3.2.2.5.7 Método ACME “tls-alpn-01” para direcciones IP

Especialmente para los dos últimos puntos, verá más detalles también en https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4 que en finas referencias al protocolo ACME publicado recientemente como un RFC: https://tools.ietf.org/html/rfc8555

Pequeño rincón oscuro de las directrices del CAB Forum

Hay algunos puntos que las CA no suelen conocer bien ni hacer cumplir espectacularmente. Pero en resumen, deberían revocar cualquier certificado tan pronto como las propiedades subyacentes ya no se validen. Por ejemplo, si un dominio no es renovado por el propietario actual y registrado por otro, entonces el certificado existente debe ser revocado.

Lo mismo ocurre con las direcciones IP: si el propietario del bloque cambia, los certificados existentes deben ser revocados.


Solución 3:

Con respecto al uso de producción, cloudflare-dns.com se conoce más comúnmente como 1.1.1.1. Las SAN del certificado incluyen las direcciones IPv4 e IPv6 del servicio.

Sospecho que una razón para tal certificado es implementar DNS sobre TLS. También responde a https, puede ver el certificado en su navegador: https: //[2606:4700:4700::1111]


Las implementaciones que admiten subjectAltName pero no iPAddress v6 son un error.

Hay pocos ejemplos de solicitudes de certificados iPAddress, y aún menos con v6. Gracias a FreeIPA por probar v6 cuando recientemente agregaron certificados de dirección IP. La solicitud de certificado se puede generar con NSS así:

certutil --extSAN dns:host.example.com,ip:2001:db8:3902:3468::443

Solución 4:

Existe un proyecto para darle un nombre a cada dirección IPv6. Tienen una imagen de Docker correspondiente que ejecuta Let’s Encrypt en esos nombres. Esto no es exactamente lo mismo que “un certificado para una dirección IPv6”, pero está bastante cerca y está automatizado.

  • https://ungleich.ch/u/blog/has-a-name-for-every-ipv6-address/
  • https://ungleich.ch/u/blog/fully-automated-ssl-certificates-for-docker/

valoraciones y reseñas

Ten en cuenta dar recomendación a este ensayo si te fue de ayuda.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *