1. No, non è generalmente non possibile, purché tutti i certificati siano generati con il valore di campo X.509 corretto e Extended Key Usage (EKU) X e tutti i server TLS rispettano RFC

Per un certificato client , EKU dovrebbe contenere il valore TLS Web Client Authentication e per un certificato server , dovrebbe contenere il valore TLS Web Server Authentication . (Nota che sto fornendo una descrizione leggibile dagli umani dei campi e dei valori, non i valori effettivi di OID ).

È comune che le autorità di certificazione includano anche TLS Web Client Authentication valore in un certificato server , che non è male di per sé ( almeno personalmente non vedo uno scenario di attacco qui), ma non viceversa.

Prendi il certificato StackExchange come esempio:

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. Inoltre, un certificato server contiene il nome di dominio di un server nei campi Subject o Subject Alternative Name X.509. Per StackExchange appare come segue:

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, <...>

Qui, Common Name nel certificato è uguale a *.stackexchange.com e Subject contiene Common Name .

Ora, per iniziare a rilasciare i certificati client, di solito devi creare uno schema di denominazione , cioè cosa hai inserito nel campo Subject e nel campo% co_de nidificato. Il modo in cui lo fai dipende completamente da te, ma assicurati che in nessun caso un Common Name all'interno di un certificato client coincida con un Common Name di uno dei tuoi domini, nel caso in cui la tua CA o alcuni dei TLS- le applicazioni avanzate nella tua infrastruttura non obbediscono rigorosamente a RFC.

Un modo semplice per garantire che questo sia quello di inserire il nome completo di un utente in Common Name e quindi assicurarsi che ogni certificato client emesso contenga uno spazio , o non contengono un punto . Per quanto ne so, almeno uno di questi due requisiti potrebbe essere soddisfatto con praticamente qualsiasi nome completo esistente nel mondo.

Penso che tu stia mescolando due concetti diversi che usano parole simili "verificando" o "convalidando".

Ordinazione dei certificati

Questo è il processo in cui,

• Se si tratta di un server, l'amministratore del server creerà un CSR (richiesta di firma del certificato) e lo invierà alla CA, o altrimenti ordinerà un certificato.
• Le persone che eseguono la CA (forse gli effettivi umani, forse automatizzati) verificano i dettagli nella CSR, ovvero se stai richiedendo un certificato per www.mysite.com , ne possiedi effettivamente% codice%? Se stai richiedendo un certificato cliente per www.mysite.com , sei effettivamente quell'utente? ecc.

È sicuramente possibile ingannare una CA nel darti un certificato che non dovresti avere, ma di solito non usi la parola "man-in-the-middle" qui, dovresti invece dire "emettere un falso certificato".

Non ci hai detto come i tuoi server e client ordinano i certificati dalla tua CA autofirmata, ma mi auguro che ci siano alcuni umani che guardano e approvano manualmente ogni richiesta, o qualche altro processo per impedire l'emissione di certificati fraudolenti . Se i clienti possono ordinare altri client, sarebbe sicuramente negativo, ma nella tua domanda non ci sono abbastanza informazioni per capire se è possibile.

Intercettazione del traffico web

Questo è il punto in cui parlerai di attacchi "man-in-the-middle", cioè dove pensi di parlare con il vero [email protected] , ma in realtà stai parlando con un attaccante che ha un falso certificato per quel sito.

Sembri preoccupato che qualcuno possa ottenere un certificato client con il nome del server al suo interno?

• Prima di tutto, come accennato in precedenza, il "certificato di rilascio" umano cliccando questo tipo di trucco e non dare il certificato.
• In secondo luogo, un certificato client non dovrebbe essere in grado di agire come un server. Le CA inseriranno un campo chiamato www.mysite.com o Extended Key Usage (EKU) che indica se questo certificato è un client o un server o entrambi. Devi assicurarti che la CA includa questo nei certificati che emette e che i tuoi clienti stiano verificando l'EKU del server prima di accettare la connessione.

Purché tutti i certificati siano univoci (nessun singolo certificato è condiviso tra due o più entità) e la CA radice è attendibile, non esiste alcun modo per MITM.

Cioè, il server e ogni client devono avere il proprio certificato univoco e solo il proprietario del certificato possiede la chiave privata. Inoltre, configurare il server per convalidare i certificati emessi dalla propria CA e solo la CA è autorizzata a emettere certificati di autenticazione client. Si tratta di nozioni di autenticazione basate su certificati. Ovviamente, è necessario implementare le corrette operazioni di CA per evitare errori di emissione dei certificati, sviluppare procedure di revoca e così via.

Inoltre, potrebbe essere necessario un database con i client e un certificato mappa per l'account del cliente per scopi di controllo e autorizzazione. Il server può utilizzare queste informazioni per applicare restrizioni ai client.