1. No, no es posible en general , siempre que todos los certificados se generen con el valor de campo <.o9 <% de Extended Key Usage (EKU) y todos sus servidores TLS respeten RFC .

Para un certificado de cliente , EKU debe contener el valor TLS Web Client Authentication , y para un certificado de servidor , debe contener el valor TLS Web Server Authentication . (Tenga en cuenta que proporciono una descripción legible para los humanos de los campos y los valores, no los valores OID reales .)

Es común que las autoridades de certificación incluyan también el valor TLS Web Client Authentication en un certificado de servidor , que no es malo en sí mismo ( al menos personalmente no veo un escenario de ataque aquí), pero no al revés.

Tome el certificado StackExchange como ejemplo:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication

2. Además, un certificado de servidor contiene el nombre de dominio de un servidor en los campos Subject o en los campos Subject Alternative Name X.509. Para StackExchange se ve así:

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        <...>
        X509v3 Subject Alternative Name:
            DNS:*.stackexchange.com, DNS:stackoverflow.com, <...>

Aquí, el Common Name en el certificado es igual a *.stackexchange.com , y Subject contiene el Common Name .

Ahora, para comenzar a emitir certificados de cliente, normalmente tiene que crear un esquema de nombres , es decir, lo que coloca en el campo Subject y el campo anidado Common Name . La forma de hacerlo depende completamente de usted, pero es mejor asegurarse de que bajo ninguna circunstancia un Common Name dentro de un certificado de cliente coincida con un Common Name de uno de sus dominios, en caso de que su CA o alguno de los TLS- Las aplicaciones mejoradas en su infraestructura no obedecen a RFC estrictamente.

Una forma sencilla de garantizar esto es poner el nombre completo de un usuario en el Common Name y luego asegurarse de que cada certificado de cliente emitido o hace contiene un espacio , o no contiene un punto . Que yo sepa, al menos uno de esos dos requisitos podría satisfacerse con casi cualquier nombre completo que exista en el mundo.

Creo que estás mezclando dos conceptos diferentes que usan palabras similares "verificar" o "validar".

Solicitud de certificados

Este es el proceso donde,

• Si se trata de un servidor, el administrador del servidor creará una CSR (solicitud de firma de certificado) y la enviará a la CA, o bien solicitará un certificado.
• Las personas que ejecutan la CA (tal vez personas reales, tal vez automatizadas) verificarán los detalles en la CSR, es decir, si está solicitando un certificado para www.mysite.com , ¿realmente posee% código%? Si está solicitando un certificado de cliente para www.mysite.com , ¿es realmente ese usuario? etc.

Definitivamente, es posible engañar a una CA para que le otorgue un certificado que no debería tener, pero por lo general no usa la palabra "man-in-the-middle" aquí, sino que diría que "emitir un documento fraudulento certificado ".

No nos ha dicho cómo sus servidores y clientes solicitan certificados de su CA autofirmada, pero espero que haya personas que estén observando y aprobando manualmente cada solicitud, o algún otro proceso para evitar que se emitan certificados fraudulentos . Si los clientes pueden pedir otros clientes, eso definitivamente sería malo, pero no hay suficiente información en su pregunta para saber si eso es posible.

Interceptar tráfico web

Aquí es donde hablará sobre los ataques de "hombre en el medio", es decir, cuando cree que está hablando con el [email protected] real, pero en realidad está hablando con un atacante que tiene un fraude. cert para ese sitio.

¿Parece que le preocupa que alguien pueda obtener un certificado de cliente con el nombre del servidor?

• Primero que nada, como se mencionó anteriormente, el clic humano en "emitir certificado" notará este tipo de truco y no otorgará el certificado.
• Segundo, un certificado de cliente no debe poder actuar como un servidor. Las CA colocarán un campo llamado www.mysite.com o Extended Key Usage (EKU) que indica si este certificado es un cliente o un servidor o ambos. Debe asegurarse de que su CA lo incluya en los certificados que emite y de que sus clientes estén comprobando el EKU del servidor antes de aceptar la conexión.

Mientras todos los certificados sean únicos (no se comparte un único certificado entre dos o más entidades) y se confía en la CA raíz, no hay forma de que MITM

Es decir, el servidor y cada cliente deben tener su propio certificado único y solo el propietario del certificado posee la clave privada. Además, configure el servidor para validar los certificados emitidos por su propia CA y solo su CA está autorizada para emitir certificados de autenticación de clientes. Estos son los conceptos básicos de autenticación basada en certificados. Por supuesto, debe implementar las operaciones de CA adecuadas para evitar la emisión errónea de certificados, desarrollar procedimientos de revocación, etc.

Además, es posible que necesite una base de datos con clientes y un certificado de asignación a la cuenta del cliente para fines de auditoría y permisos. El servidor puede usar esta información para aplicar restricciones a los clientes.