Sus principios son correctos, pero los detalles pueden ser un demonio para corregirlos.
De hecho, el esquema general es que:
-
El cliente debe validar el certificado del servidor, es decir, verificar que el certificado haya sido emitido (firmado) por una CA de confianza, y que el certificado del servidor presunto contenga el nombre del servidor.
-
Del mismo modo, el servidor debe validar el certificado del cliente, es decir, verificar que el certificado haya sido emitido (firmado) por una CA de confianza, y luego obtenga el "nombre del cliente" del certificado.
Por lo tanto, tanto el cliente como el servidor deben confiar en algún certificado de CA raíz, no necesariamente lo mismo (pero no hace daño que ambos confíen en lo mismo). Además, tanto el cliente como el servidor pueden ser un poco exigentes sobre lo que encuentran en su propio certificado y en el certificado del par. El certificado del servidor deberá contener el nombre del servidor según lo prescrito en RFC 2818 (sección 3.1). Si incluye la extensión Extended Key Usage , entonces IIS e Internet Explorer tenderán a requerir el uso de la clave de "autenticación del servidor" (1.3.6.1.5.5.7.3.1). Para el certificado de cliente, IE e IIS volverán a querer ver un uso de clave específico, a saber, "autenticación de cliente" (1.3.6.1.5.5.7.3.2).
El servidor (IIS) también debe hacer algo con lo que encuentra en el certificado del cliente. Hay varios métodos. La "asignación de cuentas" se trata de asociar el certificado del cliente con una cuenta del cliente, siendo las cuentas la noción de identidad que prevalece dentro de un sistema operativo Windows. Si un dominio de Active Directory está en vigor, la asignación puede ser directa (el certificado se asigna a la cuenta que, en el servidor AD, contiene una copia del certificado) o indirecta (el certificado contiene una copia de Nombre principal del usuario de la cuenta, en su Subject Alt Name extensión). También es posible la autenticación no asignada, en cuyo caso la aplicación es responsable de dar sentido al certificado.
Revocación de certificados también puede ser un problema. Conceptualmente, una CA que ha emitido un certificado puede "expresar remordimiento", y anunciar al Mundo en general que un certificado dado, aunque aparentemente todo firmado y firmado y válido, debe ser rechazado. Esto soporta situaciones de emergencia tales como una clave privada robada. Este anuncio utiliza una Lista de revocación de certificados , un objeto de corta duración firmado por la CA. Tanto el servidor como el cliente pueden desear obtener una CRL nueva que cubra el certificado que intentan validar. Su PKI no se publica regularmente en la CRL, por lo que si el cliente o el servidor obtienen en su cabeza para verificar el estado de revocación, las cosas fallarán.
El hecho de que IIS y / o IE participen en la verificación de revocación depende de lo que encuentren en los certificados, pero eso no está documentado con la mayor claridad. IIS se puede configurar hacer caso omiso de los cheques de revocación. Para Internet Explorer, esto también se puede hacer, aparentemente en una zona base (IE clasifica los servidores en "zonas", como "intranet local" o "Internet", y puede aplicar diferentes configuraciones de seguridad para cada zona, una de las cuales es "hacer cumplir la verificación del estado de revocación").
Esta publicación del blog parece cubrir su situación. Te sugiero que sigas sus indicaciones. No juegue con la revocación a menos que reciba algunos mensajes de error que indiquen que no se pudo obtener alguna verificación del estado de la revocación, en cuyo caso tendrá que crear una CRL y enviarla tanto al cliente como al servidor (con mmc.exe ), o desactivar verificaciones de revocación (como se indica arriba).