security - tls - ¿Qué partes del certificado del cliente se deben usar para identificar a los usuarios de forma exclusiva?
proveedores certificados ssl (3)
Estoy diseñando un sistema donde los usuarios podrán registrarse y luego autenticarse con certificados de clientes además de la autenticación de nombre de usuario / contraseña.
Los certificados del cliente deberán ser certificados válidos emitidos por una lista configurada de autoridades de certificación y se verificarán (validarán) cuando se presenten.
En la fase de registro, necesito almacenar parte (s) del certificado del cliente en un repositorio de usuario (DB, LDAP, lo que sea) para que pueda mapear al usuario que se autentica con el certificado del cliente a un "usuario" interno.
Una elección bastante obvia sería usar huella digital de certificado; Pero la huella digital en sí misma no es suficiente, ya que pueden producirse colisiones (aunque no sean probables), por lo que debemos almacenar información adicional del certificado. Esta pregunta SO también es informativa a este respecto.
RFC 2459 define (4.1.2.2) que el número de serie del certificado debe ser único dentro de una CA dada.
Con todo esto combinado, estoy pensando en almacenar el número de serie del certificado y el emisor del certificado para cada usuario registrado. Dado que los certificados del cliente serán verificados y válidos, esto debe identificar de manera única cada certificado del cliente. De esta forma, incluso cuando se renueve el certificado del cliente, aún sería válido (el número de serie se mantiene igual y también lo hace el emisor).
¿Me he perdido algo?
Decidí concatenar el nombre del emisor, un delimitador | y el DN.
Con suerte, esto resuelve el problema del uso de números de serie que cambian con la renovación.
La mejor manera de identificar de manera única a un usuario es a través de una dirección de correo electrónico. En el proceso de registro, una dirección de correo electrónico válida debe ser obligatoria. A continuación, asocie el número de serie del certificado y el emisor o quizás un hash del certificado en sí con el correo electrónico y la identificación del usuario. Luego, cuando el certificado expire o el usuario cambie el certificado, tendrá un "enlace de renovación de certificado" donde ingresará la dirección de correo electrónico y recibirá un enlace para cargar el nuevo certificado. Luego puede reemplazar el antiguo serial / issuer por el nuevo.
Tienes varias soluciones:
Almacenando una huella dactilar Sí, tiene razón, una colisión es teóricamente posible, pero la probabilidad es muy baja y puede considerar que no ocurre: 2 usuarios de su sistema no tendrán accidentalmente la misma huella digital de certificado. Sin embargo, los algoritmos hash se están volviendo más débiles con el tiempo y un atacante puede intentar falsificar un certificado cuya huella digital coincida con una registrada. Este ataque se denomina segundo ataque de preimagen y es bastante difícil de hacer ya que el atacante no intenta forjar algunos datos aleatorios que coincidan con la huella digital, sino un certificado real X.509 que puede pasar la fase de validación inicial (es decir, piratear la PKI). Bastante duro :) Pero si realmente quieres evitar la colisión, puedes almacenar 2 huellas dactilares con 2 algoritmos distintos (por ejemplo, SHA-1 y SHA-256).
Almacenar el emisor del certificado y el número de serie. Sí, puede usarse como un identificador de certificado único. Como usted escribió, el estándar ( RFC 5280 obsoleto RFC 2459) indica que
[The serial number] MUST be unique for each certificate issued by a given CA.Sin embargo, también significa que cuando se renueva el certificado, el número de serie cambia ya que la CA emite un nuevo certificado.
Una observación final: desea gestionar la renovación del certificado y es una buena idea, muchos editores de software olvidan que los certificados deben renovarse. Pero debe tener en cuenta que casi todo puede cambiar en el certificado: el nombre del sujeto (las personas pueden cambiar su nombre, las mujeres se casan ...), el nombre del emisor (la compañía proveedora del certificado puede cambiar ...), el algoritmo clave , el tamaño de la clave, las extensiones ... En su sistema, el proceso de renovación del certificado probablemente sea bastante similar al registro del certificado de usuario inicial.