Cómo validar un certificado de cliente

Desde una perspectiva de alto nivel, deben suceder tres cosas:

1. El cliente debe demostrar que es el propietario adecuado del certificado del cliente. El servidor web desafía al cliente a firmar algo con su clave privada, y el servidor web valida la respuesta con la clave pública en el certificado.

2. El certificado debe ser validado contra su autoridad de firma Esto se logra verificando la firma en el certificado con la clave pública de la autoridad de firma. Además, las listas de revocación de certificados (CRL) se verifican para garantizar que el certificado no haya sido incluido en la lista negra.

3. El certificado debe contener información que lo designe como usuario válido del servicio web. El servidor web está configurado para ver elementos específicos en el certificado (generalmente el campo del sujeto) y solo permite ciertos valores.

El estándar se llama "X.509" y se conoce mejor en su encarnación como el "Perfil de Internet X.509 Certificado de Infraestructura de clave pública y Lista de revocación de certificados (CRL)", más conocido como RFC 5280 . El algoritmo completo y estándar de validación de certificados se presenta en (dolor) todos los detalles en sección 6 .

No puede esperar entender seriamente cómo funciona X.509 hasta que haya realizado el esfuerzo de leer ese documento al menos una vez. Le desconcertará, pero eso se debe a que los certificados y la PKI son una cuestión intrínsecamente compleja, que requiere nociones muy precisas de lo que es una identidad, una autenticación, una clave privada y la confianza. X.509 intenta abordar esta complejidad desde el principio, lo que lleva a estándares similares a Behemoth como RFC 5280.

Marcar la clave privada como "no exportable" es solo una ilusión; hace que sea un poco más difícil para los usuarios no técnicos exportar su clave. Una mejor respuesta sería que no debería importar . Un usuario se autentica a sí mismo al demostrar su control de la clave privada asociada con su certificado. Si el usuario desea almacenar su clave privada en otro lugar, ese es su negocio; de la misma manera que no importa si coloca la llave de la puerta en el bolsillo del pantalón izquierdo o en el bolsillo del pantalón derecho . Y, de manera similar, si deja la llave de su puerta debajo del felpudo y alguna persona extraña la toma desde allí, entonces su seguridad desaparece, pero su compañía de seguros señalará que es su culpa.

Los certificados pueden contener una variedad de parámetros que se pueden usar para limitar el uso del certificado. Por ejemplo, se puede emitir un certificado con el nombre de la aplicación y el nombre de usuario, por lo que la aplicación puede confirmar que el certificado es válido para la aplicación en particular, luego realizar la validación estándar del certificado x.509 y luego limitar las credenciales de usuario aceptables a las de la persona. a quién se le emitió el certificado.

Esta es una utilización robusta de los certificados del lado del cliente que requiere que la empresa que publica la aplicación especifique y / o controle la emisión de los certificados y que la autenticación basada en el certificado finalice o se pase a la misma capa arquitectónica que autentica Las credenciales de usuario. [En otras palabras, los concentradores SSL / TLS pueden causar problemas.]

NOTA: Los campos adicionales en el certificado están protegidos criptográficamente, por lo que, mientras están visibles, no pueden cambiarse sin destruir la validez del certificado. Como resultado, la inclusión de estos parámetros no se puede falsificar con menos dificultad que falsificar todo el certificado.

REFERENCES

• Una pregunta directamente relacionada: Adición de datos personalizados en X.509 certificado
• Guía de Microsoft -
  enlace
• artículo de Wikipedia -    enlace

En primer lugar, realmente creo que necesita identificar qué está sucediendo exactamente con la certificación de clave privada:

1. Clave privada: esto es algo que debe mantener en secreto, solo para sus ojos.
2. Clave pública: esto es algo que los usuarios usarán para que puedan comunicarse con usted (es como si estuviera usando un idioma que solo el propietario de la clave privada conoce).
3. Certificado: esto es algo para validar que la clave pública es en realidad la asociada al propietario de la clave privada.

Entonces, considera que un certificado es algo público que puedes regalar sin preocuparte por eso.

¿Cómo funciona un certificado? Permítame ponerlo en palabras simples: al emitir una clave pública, la CA agrega una "marca secreta" al certificado, por lo que cuando quiere validarlo, debe enviar el certificado del propietario a la CA para que pueda verificar si La "parte secreta" está bien. Si la CA comprueba la parte secreta y es coherente, le dará el "OK" para usar la clave pública; de lo contrario, debe sospechar de ella.

Considere echar un vistazo a este diagrama de wikimedia para que pueda conocer todo el proceso de creación y validación (incluido CA):

enlace

Este otro diagrama también podría ser útil:

enlace

Además, tenga en cuenta que las CA suelen ser agencias de confianza bien conocidas y que normalmente los navegadores tienen una lista de ellas incluidas. Sin embargo, algunas entidades (generalmente agencias u organizaciones públicas) usan su propia CA y usted debe agregarla manualmente a la lista (tenga mucho cuidado al respecto ya que una CA maliciosa podría poner en peligro sus comunicaciones).

Espero que esto te ayude.

(Siéntase libre de agregar cualquier corrección de gramática / sintaxis ya que el inglés no es mi lengua materna).

Varios proyectos, como pathfinder-pki , le permitirán validar certificados de forma totalmente compatible.