Trabajar con certificados de cliente para un sitio ASP.NET MVC en IIS 6

Question

Al querer implementar la autenticación mediante certificados de cliente, estoy experimentando algunos problemas.

Primero algunos hechos

Todo el sitio utiliza SSL.Estoy usando IIS 6 (en Windows Server 2003) y he configurado el sitio para aceptar certificados de cliente, sin requerirlos.Sin embargo, la mayoría de los navegadores están implementados de manera que sólo solicitarán un certificado al usuario cuando sea estrictamente necesario.Por este motivo, el modelo de autenticación no es realmente útil.

Sugerencias propias

Mi primera idea fue establecer el HttpResponse.Status propiedad pero requiere que los caracteres antes del primer espacio sean un número entero.El estado útil para hacer que un navegador envíe un certificado de cliente es 403.7 Client certificate required entonces esto no funcionará (a menos que puedas sobrescribirlo).

También pensé que simplemente configuraría IIS para que requiera certificados de cliente para rutas específicas, pero esto, por supuesto, funciona solo con archivos físicos y no con enrutamiento.

Una posible solución es crear una carpeta específica y solicitar certificados de cliente, lo cual es más un truco que una solución.Por eso me gustaría evitar esto si alguien tiene una propuesta mejor.

Aclaraciones

He probado la respuesta del navegador tanto de Internet Explorer como de Firefox y Chrome (uso Chrome como mi navegador principal y Firefox como secundario).Ninguno de los navegadores solicita el certificado de cliente a menos que yo, en IIS, lo configure según sea necesario.

Según tengo entendido, el código de estado HTTP 403.7 está permitido, ya que el RFC 2616 solo define el código de estado como los primeros tres dígitos.Como IIS 6 devuelve el 403.7 cuando se requiere un certificado de cliente, pensé que enviarlo obligaría a IIS a entrar en un modo especial que activaría un requisito.

Supongo que el problema ahora es cómo configurar IIS para requerir un certificado dada una ruta virtual y no física.

Answer 1

No hay diferencia en el mensaje CertificateRequest enviado por un servidor cuando el certificado simplemente se solicita, en lugar de ser obligatorio.El servidor realiza la misma solicitud en ambos casos y simplemente finaliza el protocolo de enlace cuando un cliente no proporciona el certificado requerido.Por lo tanto, si su navegador parece ignorar "solicitudes", debería parecer que también ignora los "requisitos".

Verifique lo siguiente:

• ¿Está configurado su navegador para ignorar todas las solicitudes de certificado, nunca enviando una?
• ¿Está configurado su navegador para usar un certificado determinado sin solicitar al usuario?(En otras palabras, ¿cómo se sabe que el navegador no envía un certificado?)
• ¿Su servidor realmente solicita un certificado?

La forma en que pruebo este último caso es con el AbiertoSSL (también disponible en Cygwin) herramienta:

openssl s_client -connect server.y.com:443 -msg

Después de que el servidor envía su mensaje de Certificado, insertará un método CertificateRequest que está ausente si no solicita la autenticación del cliente.La salida de s_client se ve así:

<<< TLS 1.0 Handshake [length 0008], CertificateRequest
    0d 00 00 04 01 01 00 00

No estoy seguro de cómo funciona si el servidor usa la autenticación del cliente solo en rutas específicas, porque el protocolo de enlace SSL inicial se completa antes de que el cliente transmita la solicitud HTTP.Sería razonable que el servidor solicitara un nuevo protocolo de enlace en este momento, pero nunca he probado qué servidores admiten esto.

Puedes falsificar una solicitud HTTP a través de s_client manualmente, ingresando:

GET /your/path/here HTTP/1.1[Enter]
Host: server.y.com:443[Enter]
[Enter]

Si nunca ve ningún mensaje de Solicitud de certificado, su servidor no está configurado correctamente.

Especificar restricciones de seguridad basadas en la estructura de directorios es bastante común y, de hecho, puede simplificar enormemente la administración de la seguridad.No se sienta mal si esto le ofrece una solución.

403.7 no es un código de estado HTTP.¿Se trata de algún subterfugio de Microsoft de "abrazar, ampliar y extinguir"?En cualquier caso, no parece la dirección correcta a seguir, ya que se trata de un problema de la capa de transporte, no de la capa de aplicación.