HI allí. Como nadie más ha respondido, analizaré esto, pero es una advertencia: soy un desarrollador de Java/UNIX, y parte de lo que me está preguntando es específico de Microsoft. Pero aquí hay algunas respuestas:
1 - Emitir un certificado con CN = aplicación de servidor NLB-nombre de host y 'La autenticación del servidor' propósito en el dominio CA.
El objetivo es algo específico de Microsoft. Esto suena correcto, pero también, es posible que necesite que el "uso de la llave" sea algo particular. Para los certificados SSL, usualmente uso keyEncipment o KeyAgreement. A veces los sitios usan digitalSignature. Los tres son válidos en el RFC, pero a veces Microsoft es extraño sobre qué workds. Si está usando una CA de Microsoft, vería si tiene un perfil de certificado para certificados SSL y simplemente lo uso.
2 - Emita un certificado para el front-end cajas con 'Client authentication' propósito.
Igual que el n. ° 1: cada certificado necesita algún tipo de uso de clave básica. Los campos que menciona son usos extendidos, que probablemente también sean necesarios, pero no obligatorios.
3 - Importar la clave pública del certificado de fondo a los nodos de front-end ' (y viceversa).
Solo si esto es algo específico de Microsoft. En la PKI correcta, debe importar el certificado de CA de confianza que firmó SSL, pero NO debe tener que importar cada punto final (como el certificado de back end) en la interfaz.Lo probaría solo con configurar sus cadenas de CA de confianza y ver si puede hacer que funcione: su arquitectura será mucho más extensible a largo plazo.
4 - Configurar WCF para utilizar con seguridad net.tpc transporte
5 - Configurar el comportamiento del servicio (sección serviceCredentials)
6 - Configurar el extremo de cliente comportamiento (sección ClientCredentials)
Me parece bien ...
A partir de ahí, no creo que se haya perdido nada más. La clave generalmente está funcionando a través de los mensajes de error oscuros. Cada sistema tiene su propia forma inescrutable de decir qué está mal cuando falla un apretón de manos de SSL, por lo que es sobre todo tener una idea de lo que salió mal.
A partir del problema que describe, no creo que piense que su arquitectura de seguridad indica que debe hacer una comprobación de estado del certificado. Es una medida adicional que le permitiría a su sistema verificar si la CA ha revocado un certificado. Se necesita bastante infraestructura para que funcione (CRL u OCSP), por lo que no diría que debería optar por ello sin una discusión seria en su equipo sobre los riesgos que está tratando de mitigar y la probabilidad de que lo hagan. ocurrir.
¿Qué certificados de interfaz de host deben emitirse?
El nombre de host del servidor que representan.
Algo acerca de los nombres de host: algunos sistemas no funcionarán correctamente a menos que use el nombre de dominio completo. Otros no son tan exigentes. En cualquier caso, el DN de asunto del certificado debe describir de forma única el servicio, la aplicación o el servidor que representa.
Los nodos frontales están en DMZ, por lo que no tendrán acceso al dominio (CA). ¿Esto causará algún problema?
No tendrá problemas.
A MENOS - necesita hacer la verificación de estado del certificado antes mencionada. Si tiene que validar el estado del certificado, debe obtener desde el punto final (es decir, la DMZ) la información sobre el estado del certificado (la CRL o el servidor OCSP). En infraestructuras complejas, esto generalmente se hace abriendo una ruta al servidor OCSP: es un HTTP GET para un nombre de dominio fijo o IP, por lo que no es malo abrir una ruta en un firewall.
Como dije, esa sería la solución de alto nivel y seria para mitigar los riesgos. Podría ser excesivo para su sistema: no sé lo suficiente sobre su sistema para decirle si está garantizado o no.