Lo stack mnet / iis di .net supporta le whitelist per l'autenticazione bidirezionale per le connessioni SSL / TLS?

Question

Lo stack mnet / iis di .net supporta le whitelist per l'autenticazione bidirezionale per le connessioni SSL / TLS?

#1 da (3 voti)
#2 da (1 voti)

2

Vorrei limitare l'accesso ad alcune delle mie API REST, in modo tale che solo le connessioni SSL / TLS bidirezionali siano accettate, dove "l'altra parte" corrisponde a una lista bianca limitata, dettagliata.

Questo è qualcosa che è facilmente supportato dallo stack Microsoft, come parte della loro implementazione MVC - e, se lo è, c'è un esempio di come potrei usarlo?

Come bonus, sarebbe bello se posso controllare che il certificato in entrata corrisponda a un elenco di domini (cioè, controlla che il certificato sia emesso su un dominio che è nella mia lista bianca, e che la connessione provenga da quel dominio, al contrario di whitelisting alcuni indirizzi ip, quindi posso consentire ai certificati di passare da fonti di autorità attendibili e gli indirizzi IP a cambi arbitrari).

.net tls

posta blueberryfields 07.02.2014 - 23:59

fonte

2 risposte

1

Ecco come ho realizzato questo utilizzando IIS6, dovrebbe comunque essere supportato nelle versioni successive.

Verifica che il certificato del server sia installato e funzionante

Assicurarsi che la CA radice del certificato client e tutti i prodotti intermedi siano installati sul server nell'archivio di sistema

Alla voce "Comunicazioni sicure":

Abilita Richiedi canale sicuro (SSL)

Richiedi i certificati client

Abilita mappatura certificati client

Sotto il pulsante Modifica aggiungi una mappatura 1-a-1 utilizzando i certificati client a cui desideri consentire l'accesso. Dovrai utilizzare un account Windows locale con le autorizzazioni appropriate. Ho usato l'account utente anonimo locale estraendo la password utilizzando Metabase Explorer.

È possibile utilizzare facoltativamente l'elenco di certificati attendibili per creare un elenco di CA radice affidabili che devono essere emesse dal certificato client da

Esci dall'autenticazione e dal controllo di accesso, disabilita l'accesso anonimo e l'autenticazione integrata di Windows

Con questa configurazione la richiesta verrà rifiutata se non viene presentato alcun certificato client. Se viene presentato un certificato client che non corrisponde a uno di quelli nel mapping 1-a-1, la richiesta verrà rifiutata poiché l'accesso anonimo è disabilitato e non può essere mappato su un utente valido.

risposta data 07.05.2014 - 16:10
fonte

Leggi altre domande sui tag .net tls

Il blocco del certificato è diverso da quello di CA? Come implementare il requisito 3.5.2 PCI DSS?

score 3 · Accepted Answer

La tua domanda è piuttosto poco chiara perché ogni connessione TLS è, per sua natura, bidirezionale: consente ai byte di scorrere in entrambe le direzioni. Io supponiamo che intendi le connessioni in cui sia il client che il server mostrano un certificato.

Sul lato client , il certificato del server viene accettato se si tiene tutto il seguente:

Il certificato del server può essere validato , cioè messo alla fine di una catena di certificati, che inizia con una root attendibile , e tutti i nomi, le firme e varie le estensioni corrispondono lungo la catena.
Lo stato di revoca di tutti questi certificati può essere verificato come "non revocato" con informazioni sufficientemente aggiornate (ottenute da risposte CRL e / o OCSP).
Il nome del server previsto , ovvero il nome visualizzato nell'URL utilizzato dal client, viene visualizzato nel certificato del server (nell'estensione Subject Alt Name , come per RFC 2818 ).

Per impostazione predefinita, il codice client .NET si baserà sul set di root attendibili valido per l'account con cui viene eseguito il codice client; questa è una fusione degli archivi certificati "root" per "utente corrente", "macchina locale" e "impresa".

Sul lato server , il certificato del client può essere convalidato da IIS. In tal caso, IIS ha due modalità:

clientCertificateMappingAuthentication : il certificato client è validato rispetto all'insieme di root attendibili del server; la CA di emissione (quella che ha immediatamente firmato il certificato client) deve far parte dell'archivio NTAuth aziendale; e quindi l'UPN viene estratto dal certificato client e cercato nel server di Active Directory locale. La parte relativa all'archivio "NTAuth" è dove puoi limitare i certificati client.

iisClientCertificateMappingAuthentication : IIS fa il lavoro, non il server AD (ad es. è quello che fai se il server non fa parte di un dominio). Dopo la convalida con le root attendibili, IIS può eseguire un "mapping one-to-one" in cui un certificato client sarà accettato solo se è identico bit-a-bit a un certificato registrato in IIS e quindi mappato a un'identità specifica .

Esistono molte opzioni di configurazione. E puoi sovrascrivere a livello di codice la maggior parte delle parti del processo. Ad esempio, vedi questa pagina per come configurare sul server una classe personalizzata per la convalida dei certificati client ; con una classe del genere, puoi fare tutto ciò che desideri (ma attenzione, puoi anche fare cose molto deboli, come fidarti del certificato sul valore nominale senza alcuna convalida).