I tuoi principi sono corretti, ma i dettagli possono essere un diavolo da impostare.
In effetti, lo schema generale è questo:
-
Il client deve convalidare il certificato dal server, cioè verificare che il certificato sia stato emesso (firmato) da una CA attendibile, e che il presunto certificato del server contenga nome del server.
-
Allo stesso modo, il server deve convalidare il certificato dal client, cioè verificare che il certificato sia stato emesso (firmato) da una CA attendibile, e quindi ottenere il "nome client" dal certificato.
Quindi sia il client che il server devono considerare attendibile un certificato CA radice, non necessariamente lo stesso (ma non fa male che entrambi abbiano fiducia nello stesso). Inoltre, sia il client che il server possono essere un po 'pignoli su ciò che trovano nel proprio certificato e nel certificato dal peer. Il certificato del server dovrà contenere il nome del server come prescritto da RFC 2818 (sezione 3.1). Se si include l'estensione Extended Key Usage , IIS e Internet Explorer tenderanno a richiedere l'utilizzo della chiave "autenticazione server" (1.3.6.1.5.5.7.3.1). Per il certificato client, IE e IIS vorranno nuovamente vedere un utilizzo specifico della chiave, ovvero "autenticazione client" (1.3.6.1.5.5.7.3.2).
Il server (IIS) deve anche creare qualcosa da ciò che trova nel certificato client. Ci sono diversi metodi. "Account mapping" riguarda l'associazione del certificato client con un account del cliente, essendo gli account la nozione di identità che prevale all'interno di un sistema operativo Windows. Se è attivo un dominio di Active Directory, la mappatura può essere diretta (il certificato viene mappato sull'account che, sul server AD, contiene una copia del certificato) o indiretto (il certificato contiene una copia di Nome principale utente dell'account, in Subject Alt Name estensione). Anche l'autenticazione non mappata è possibile, nel qual caso l'applicazione è responsabile del senso del certificato.
Anche la revoca dei certificati può essere un problema. Concettualmente, una CA che ha emesso un certificato può "esprimere rimorso" e annunciare al mondo in generale che un determinato certificato, sebbene apparentemente tutto firmato, firmato e valido, deve comunque essere respinto. Questo supporta situazioni di emergenza come una chiave privata rubata. Questo annuncio utilizza un elenco di revoca dei certificati , un oggetto di breve durata firmato dalla CA. Sia il server che il client possono desidera ottenere un nuovo CRL che copra il certificato che stanno tentando di convalidare. La tua PKI fatta in casa non pubblica regolarmente CRL, quindi se il client o il server ottiene in testa per verificare lo stato di revoca, le cose falliranno.
Se IIS e / o IE eseguiranno il controllo di revoca dipende da cosa trovano nei certificati, ma ciò non è documentato con la massima chiarezza. IIS può essere configurato ignorare i controlli di revoca. Per Internet Explorer, questo può anche essere fatto, apparentemente su una zona base (IE classifica i server in "zone", come "intranet locale" o "Internet", e può applicare diverse impostazioni di sicurezza per ciascuna zona, una delle quali è "impone il controllo dello stato di revoca").
Questo post del blog sembra coprire la tua situazione. Ti suggerisco di seguire le sue indicazioni. Non giocherellare con la revoca a meno che non si ottengano alcuni messaggi di errore che indicano che non è stato possibile ottenere il controllo dello stato di revoca, nel qual caso potrebbe essere necessario creare un CRL e inviarlo su client e server (con mmc.exe ) o disattivare controlli di revoca (come indicato sopra).