Windows Server 2012R2 - Root attendibile CA Store (computer locale) non elencato in SERVER HELLO / CERTIFICATE Richiesta di archiviazione di handshake TLS1.2

Question

Windows Server 2012R2 - Root attendibile CA Store (computer locale) non elencato in SERVER HELLO / CERTIFICATE Richiesta di archiviazione di handshake TLS1.2

#1 da (3 voti)

3

la mia azienda ha sviluppato un'applicazione basata su .net (basata su SChannel) finalizzata all'esecuzione dell'autenticazione reciproca TLS1.2 tra 2 istanze dello stesso SW, una che funge da client e l'altra come server nella sessione di autenticazione reciproca TLS1.2 .

Entrambe le istanze SW client e server sono state distribuite su diversi server Windows OS (2008R2 e 2012R2).

Abbiamo testato con successo l'applicazione su un sistema operativo Windows Server 2008 R2 (entrambe le istanze SW "client" e "server" in esecuzione su WIN 2008R2 OS); in tal caso, il server fornisce, all'interno del messaggio "Server Hello" iniziale dell'handshake TLS1.2 nella sezione "Richiesta certificato", un elenco di "Nomi distinti" che corrisponde al contenuto dell'archivio certificati CA Root attendibile (locale Computer) in esecuzione sullo stesso server, secondo lo standard RFC TLS1.2.

Tuttavia, quando si esegue la stessa applicazione (utilizzando lo stesso set di certs) su un ambiente OS Win2012 R2, durante il messaggio Server Hello, la parte Richiesta certificato continua a restituire un elenco DN vuoto (ovvero, il certificato 0 viene elencato) , anche se lo stesso set di CA Trusted Root è disponibile nel Trusted Store di CA (Computer locale).

Quando il SW agisce come client nell'handshake TLS1.2, in esecuzione su 2008R2 o 2012R2, il SW può utilizzare con successo un certificato di autenticazione client reso disponibile / installato sotto Computer locale - > Personale - > Certificati.

Non ero coinvolto nello sviluppo del codice della funzione crittografica del programma, ma ho la sensazione che potrei semplicemente mancare alcune impostazioni aggiuntive introdotte a livello di sistema operativo quando si passa da 2008R2 a 2012R2 piuttosto che avere un problema SW - quindi I si chiedeva se qualcuno potesse suggerire possibili impostazioni del sistema operativo che potrebbero dover essere adattate.

Grazie

authentication public-key-infrastructure tls certificates windows-server

posta Ottootto 23.12.2016 - 16:15

fonte

1 risposta

Leggi altre domande sui tag authentication public-key-infrastructure tls certificates windows-server

La "polvere" dei dati non è presente sull'HDD? Trova algoritmo hash e fattore di lavoro

score 3 · Accepted Answer

Comportamento previsto su Win2012. Invia come è, o forza tramite registro.

Non ho mai configurato l'autenticazione cert client su alcun IIS, ma penso di aver scoperto che cosa c'è che non va: "SendTrustedIssuerList" è impostato su OFF in Win2012.

Il lato server dell'autenticazione TLS reciproca funziona in modo diverso in Win2012. Vale a dire: Il comportamento per inviare l'elenco degli emittenti attendibili è disattivato per impostazione predefinita : Il valore predefinito della chiave di registro SendTrustedIssuerList è ora 0 (disattivato per impostazione predefinita) (archiviato qui .) Sembra che tu possa farlo manualmente nelle precedenti versioni del server Windows, ma ora è l'impostazione predefinita.

Inoltre ciò che ora sembra essere Win2012 è un processo di ricerca attraverso tre archivi di certificati per CA di certificati client accettabili (Archiviato qui .). (Ovvero non è più necessario l'ingombrante processo di generazione dell'elenco di CA accettabili tramite un "CTL" / "Elenco di certificati attendibili" e invece spostare / copiare CA accettabili in nuovi archivi di certificati.)

TUTTAVIA: anche se tale "Elenco degli emittenti attendibili" deve essere generato INTERNAMENTE, NON viene inviato ESCLUSIVAMENTE al cliente. E questo perché SendTrustedIssuerList ora imposta di default 0 .

Quindi la soluzione sembra essere:

Verifica che il processo a tre store sia impostato correttamente sul lato server.

E per le applicazioni interattive:

Se insisti a inviare CA accettabili al client, forza SendTrustedIssuerList a 1 . Ma poi si aspetta che il client Safari di Apple fallisca. . (Mi aspetto che questo non sia un problema, dato che questo sarebbe già successo nella configurazione di Win2008r2 e non lo hai menzionato.)
Se non si insiste nell'inviare le CA accettabili al cliente, allora lasciare così com'è. Ma prevede una "finestra di dialogo di selezione del cliente qui" più grande sui tuoi clienti , poiché non le offri più suggerimenti sui certificati client accettabili. (Ma di nuovo i browser client di solito non hanno davvero tanti certificati client tra cui scegliere. Quindi l'elenco sarà probabilmente breve.)

E per applicazioni non interattive, come nel tuo caso:

O per forzare il lato client a fornire il certificato client giusto senza ottenere il suggerimento.
O per forzare il server a inviare il suggerimento e il lato client a prendere il suggerimento.