Tengo el requisito de limitar los certificados SSL por IP de origen.
¿La configuración de un SubjectAltName crítico limitaría esto (la validación del lado del servidor es mediante OpenSSL a través de nginx)? Si no, ¿cómo se podría implementar esto?
No. SubjectAltName da nombres alternativos, por lo que significa que el certificado es válido para el nombre Subject y también para cualquier nombre que aparezca debajo de SubjectAltName . No crea un requisito adicional a cumplir, da un requisito alternativo a cumplir.
Por lo tanto, un certificado del lado del servidor con los nombres alternativos "www.example.com" y "192.168.1.5" se considerará válido para https://192.168.1.5/ OR https://www.example.com/ . No se deben cumplir ambos criterios, solo uno de ellos.
Sin embargo, dicho certificado no coincidirá con la url https://test.example.com/ incluso si la dirección IP de test.example.com fuera de hecho 192.168.1.5 . Solo se comprueba el nombre que aparece en la URL.
Para limitar el uso de un certificado a una IP particular, necesita implementar sus propias restricciones, probablemente a nivel de aplicación. Es decir. tendrá que escribir el código que verifica la IP del cliente y el certificado y valida que se cumplan las reglas, devolviendo un código de estado HTTP adecuado, si no.
Lo que haga con un certificado de cliente depende completamente del servidor. No hay una regla estándar. Puede decidir, en el lado del servidor, que un certificado de cliente dado es aceptable solo si la conexión proviene de una dirección IP específica; esto depende de lo que admita el código del servidor, no del contenido del certificado.
Para el certificado de servidor , ese es validado por los clientes, y los clientes siguen (más o menos) las reglas dadas en RFC 2818 . Esto significa que los clientes esperan que el nombre del servidor (como aparece en la URL de destino) esté presente en el certificado del servidor, en su extensión Subject Alt Name (si no existe dicha extensión, los clientes buscarán en el nombre común en el asunto DN). Solo se hacen coincidir nombres (de tipo dNSName ); Aunque la extensión SAN puede contener direcciones IP (de tipo iPAddress ), dichas direcciones no son consideradas por los clientes HTTPS.
(Hay una excepción teórica: si la URL no contiene un nombre sino una representación de una dirección IP, por ejemplo, en "punto decimal", esa dirección IP coincidirá con un nombre iPAddress en la extensión SAN. se permite una coincidencia exacta; no hay una coincidencia de tipo comodín. dNSName los nombres se ignoran. Esta posibilidad se especifica en RFC 2818 pero no está claro si los navegadores existentes lo implementan, se sabe que los navegadores no siguen las reglas exactamente, en particular implementan solo un subconjunto limitado de comodines. En cualquier caso, nunca he visto eso utilizado en la naturaleza, y no sería flexible, ya que las direcciones IP son un producto sujeto a cambios, por lo que el DNS se inventó en primer lugar.)
No importa si la extensión es crítica o no. Cuando una extensión es crítica, cualquier sistema que procese el certificado debe rechazarlo por completo si no entiende la extensión. Pero la extensión semántica no se ve alterada por la criticidad. Dado que todos los clientes HTTPS razonables (y servidores, cuando solicitan certificados de cliente) son compatibles con la extensión SAN, lo que hace que los cambios críticos no hagan absolutamente nada.
Lea otras preguntas en las etiquetas certificates openssl