URIs en la extensión subjAltName X.509

Question

URIs en la extensión subjAltName X.509

#1 de Bruno (4 votos)

2

La extensión subjAltTag para certificados X.509 puede incluir nombres de dominio, direcciones de correo electrónico, URI, etc. Estaba jugando con un X.509 cuyo subjAltTag solo tenía un URI y no parece funcionar. Aquí hay una captura de pantalla:

El URI en la barra de direcciones, en la parte superior, es el mismo URI en el certificado. Actualicé mi archivo de hosts para apuntar www.google.com a localhost. Ellos certifican que el certificado de google.com ha renunciado.

Mi pregunta es ... ¿por qué no funciona? ¿Los navegadores solo admiten nombres de dominio?

Se adjuntan el certificado X.509 y su clave privada RSA correspondiente:

Aquí están los errores específicos que Firefox me está dando:

The certificate is not trusted because it is self-signed.
The certificate is not valid for any server names.

¿Alguna idea?

public-key-infrastructure tls certificates x.509

pregunta compcert 21.04.2012 - 18:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates x.509

Usando una tabla recta para almacenar contraseñas Asegurar la comunicación

score 4 · Accepted Answer

Al realizar una conexión HTTPS, las reglas utilizadas para verificar la identidad del servidor siguen siendo las que se dan en RFC 2818 (Sección 3.1) :

Si una extensión subjectAltName de tipo dNSName está presente, esa DEBE
  ser utilizado como la identidad. De lo contrario, el nombre común (más específico)
  DEBE usarse el campo en el campo Asunto del certificado. Aunque
  el uso del Nombre Común es una práctica existente, está en desuso y   Se recomienda a las autoridades de certificación que usen el dNSName en su lugar.

[...]

En algunos casos, el URI se especifica como una dirección IP en lugar de una   nombre de host En este caso, el iPAddress subjectAltName debe estar presente
  en el certificado y debe coincidir exactamente con la IP en el URI.

En su certificado, no hay ninguna extensión de Nombre alternativo del sujeto (SAN) del tipo DNS ( dNSName ). Por lo tanto, se remonta al nombre común del sujeto DN.

Una especificación más reciente ( RFC 6125 ) armoniza el procedimiento de verificación del nombre de host en otros protocolos. Sin embargo, aún no está implementado ampliamente.

Permite el uso de URI y dice esto (entre otras cosas):

[...] Por lo tanto esto documento discute los Identificadores Uniformes de Recursos [URI] solo como un forma de comunicar un nombre de dominio DNS (a través del componente URI "host") o su equivalente), no como una forma de comunicar otros aspectos de un Servicio como un recurso específico (a través del componente URI "ruta") o parámetros (a través del componente "consulta" URI).

Esencialmente, solo el esquema y el nombre de host se usan realmente desde esa URI. Esto significa que es solo más específico que una entrada de SAN DNS al limitar el uso a un determinado protocolo (ni siquiera el puerto, por lo que puedo ver en una lectura rápida).

Esta especificación solo se finalizó hace aproximadamente un año, lo cual no es tan largo. No está claro cuán ampliamente será adoptado. Para aclarar y armonizar las prácticas existentes, vale la pena el esfuerzo, pero supongo que las CA y los implementadores deberían conocerlo mejor y encontrar una demanda para emitir certificados con SAN URI, ya que no se corresponde con la especificación utilizada anteriormente (RFC 2818). Supongo que habría poca demanda por parte de los proveedores de servicios, ya que, de todos modos, pocos clientes lo admiten.

Muchos navegadores no implementan completamente RFC 2818 tal como es (por ejemplo, son más indulgentes con las direcciones IP en el CN del nombre del sujeto, sin SAN).

(Como nota al margen, desde el punto de vista del certificado de cliente, puede interesarle la WebID proyecto , que explora otras formas distintas de PKIX de verificar un certificado de cliente y hacer uso de URI en la SAN.)