Autenticación de cliente SSL / TLS: validación práctica del certificado de cliente

Question

Autenticación de cliente SSL / TLS: validación práctica del certificado de cliente

#1 de Tom Leek (2 votos)
#2 de Neil Smithline (-1 votos)

2

¿Cómo validan los certificados de cliente los servidores HTTPS reales? Mi contexto es negocio a negocio en lugar de clientes humanos regulares. Entiendo la validación de la cadena básica a un certificado CA raíz de confianza. Pero, ¿los servidores suelen tener algún tipo de configuración para especificar los nombres de los sujetos de los certificados en los que desean confiar, o los valores de huella digital?

En un caso, una CA privada que actúe en nombre del servidor podría firmar los certificados del cliente para que SOLAMENTE se acepten sus certificados. En otro escenario, el servidor confía en certificados firmados por cualquier CA "regular" de confianza (a elección del cliente) en su almacén de confianza. Pero si su sistema debe cerrarse (como en un caso de negocio a negocio), entonces desea un filtrado adicional.

En el nivel de aplicación, me doy cuenta de que si la cadena de certificados está disponible, se puede realizar cualquier otro filtrado personalizado. Pero solo quiero saber en el mundo real, fuera de la caja, qué servidores de configuración adicionales tienen que lidiar con esto hoy durante el protocolo de enlace TLS.

Gracias.

authentication tls client

pregunta Harry 20.05.2015 - 22:34

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication tls client

Métodos para la firma inmediata de certificados ¿Usar la clave del servidor para firmar digitalmente el contenido HTML que entregó?

score 2 · Answer 1

Cuando el servidor utiliza IIS, la autenticación del cliente significa asignar el certificado del cliente a una identidad , es decir, una cuenta (cuenta local o cuenta de dominio, según el contexto). IIS puede aplicar dos métodos distintos, con nombres confusos:

clientCertificateMappingAuthentication : IIS buscará para una cuenta de dominio que contiene una copia del certificado de cliente exacto, o al menos una cuenta de dominio cuyo atributo Usuario-Principal-Nombre coincide con el contenido en el certificado (como Subject Alt Name de tipo otherName , identificado con un OID especificado por Microsoft). El uso de la UPN está sujeto a algunas condiciones arcanas, incluido el almacenamiento de una copia del certificado de CA que se emite de inmediato ( no la CA raíz) en el almacén de certificados "Enterprise NTAuth" de la máquina del servidor IIS, o que del servidor AD, o tal vez ambos. Puede usar esta página del blog para obtener orientación.
iisClientCertificateMappingAuthentication : este tiene dos sub-métodos, que la documentación de IIS llama "mapeo uno a uno" y "mapeo muchos a uno". En la asignación uno a uno, la configuración de IIS contiene asignaciones explícitas de un certificado exacto (el certificado completo en Base64) a una cuenta (local o de dominio). En la asignación muchos a uno, la configuración contiene algunas reglas que básicamente coinciden con partes de IssuerDN y SubjectDN, y asignan explícitamente certificados coincidentes a una cuenta determinada.

En el mundo que no es de Microsoft, en el servidor web Apache, usaría SSLRequire para implementar reglas de acceso, basadas en elementos extraídos del certificado (en la práctica, IssuerDN y SubjectDN).

Lo que hay que recordar es que:

Los certificados son para autenticación , no para autorización . El primero es para asegurarse de quién llama, el segundo para decidir si se debe permitir a ese cliente específico realizar el acceso solicitado. El modelo de IIS realiza la autorización principalmente con derechos de acceso: una vez que el certificado se asignó a una cuenta, el resto es material específico de AD que ya no tiene relación con los certificados; esto podría ser simples derechos de acceso a archivos, o posiblemente una configuración de autorización más detallada con AzMan o lo que sea que reemplace en versiones recientes de Windows.

Tratar de hacer la autorización con certificados (por ejemplo, la emisión de certificados de clientes que contienen alguna información como "puede hacer la operación X") generalmente termina en rasgaduras y rechinamiento de los dientes. A pesar de toda su confusión, el método de Microsoft tiene el mérito de separar claramente la autenticación y la autorización.
Siempre hay un paso de validación de certificado, que garantiza que el certificado sea genuino y aceptable. Esto incluye verificar todas las fechas, firmas criptográficas, encadenamiento de nombres, estado de revocación ...
Puede haber un filtro adicional en las rutas, como lo que hace IIS al usar la asignación de certificados de cliente basada en UPN: la presencia de la CA emisora en el almacén de NTAuth de la empresa actúa como una verificación adicional que rechazará las rutas de certificados que son válidos, provienen de una raíz aceptada, pero no pasaron por la CA intermedia esperada.

score -1 · Answer 2

No estoy seguro de que haya alguna solución. Diferentes estrategias funcionan para implementar diferentes funcionalidades.

Una estrategia común para una implementación B2B es que la organización del servidor actúe como CA y firme claves públicas de los clientes. Cuando se recibe un certificado de cliente, el servidor valida la firma y luego asigna el certificado a un usuario. La asignación de usuarios se realiza normalmente mediante la extracción de un campo del certificado, pero también se puede emplear una búsqueda de certificados u otra estrategia.

La forma en que implementes esta validación y mapeo dependerá del servidor que estés usando.

Una cosa a la que se debe prestar atención es que solo puede confiar en certificados de clientes que se han utilizado en un protocolo de enlace mutuo de autenticación SSL. No dejes que el cliente te pase su certificado. Debe obtenerlo del subsistema SSL para asegurarse de que se haya validado (es decir, el cliente ha demostrado que posee la clave privada correspondiente al certificado).