Utilizzo di certificati client per un sito ASP.NET MVC su IIS 6

Question

Volendo implementare l'autenticazione tramite certificati client, riscontro alcuni problemi.

Innanzitutto alcuni fatti

L'intero sito utilizza SSL. Sto usando IIS 6 (su Windows Server 2003) e ho configurato il sito per accettare i certificati client, non richiedendoli. La maggior parte dei browser è tuttavia implementata in modo tale da richiedere all'utente un certificato solo quando è strettamente necessario. Per questo motivo il modello di autenticazione non è davvero utile.

I miei suggerimenti

La mia prima idea è stata quella di impostare la proprietà HttpResponse.Status ma richiede che i caratteri prima del primo spazio siano interi. Lo stato utile per ottenere un browser per l'invio di un certificato client è 403.7 Certificato client richiesto , quindi non funzionerà (a meno che non sia possibile sovrascriverlo).

Ho anche pensato che avrei semplicemente configurato IIS per richiedere certificati client per percorsi specifici, ma questo - ovviamente - funziona solo con file fisici e non con routing.

Una possibile soluzione è quella di creare una cartella specifica e richiedere certificati client per essa che è più un hack che una soluzione. Quindi vorrei evitarlo se qualcuno avesse una proposta migliore.

Chiarimenti

Ho testato la risposta del browser di Internet Explorer, Firefox e Chrome (utilizzo Chrome come browser principale e Firefox come secondario). Nessuno dei browser richiede il certificato client a meno che I - in IIS - non lo configuri come richiesto.

Il codice di stato HTTP 403.7 è dovuto alla mia comprensione consentita poiché RFC 2616 definisce il codice di stato solo come le prime tre cifre. Dato che IIS 6 restituisce il 403.7 quando è richiesto un certificato client, ho pensato che l'invio forzerebbe IIS in una modalità speciale che innesca un requisito.

Immagino che il problema ora sia come configurare IIS per richiedere un certificato dato un percorso virtuale e non fisico.

Answer 1

Non c'è alcuna differenza nel messaggio CertificateRequest inviato da un server quando il certificato viene semplicemente richiesto, anziché richiesto. Il server effettua la stessa richiesta in entrambi i casi e termina semplicemente l'handshake quando un client non riesce a fornire un certificato richiesto. Pertanto, se il tuo browser sembra ignorare le "richieste", dovrebbe sembrare che ignori i "requisiti". anche.

Verifica quanto segue:

• Il tuo browser è configurato per ignorare tutte le richieste di certificati, mai inviando uno?
• Il tuo browser è configurato per utilizzare a dato certificato senza richiesta l'utente? (In altre parole, come fai a sapere che il browser non sta inviando un certificato?)
• Il tuo server sta effettivamente richiedendo a certificato?

Il modo in cui collaudo quest'ultimo caso è con OpenSSL (disponibile anche in Cygwin ) strumento:

openssl s_client -connect server.y.com:443 -msg

Dopo aver inviato il messaggio Certificato, il server inserirà un metodo CertificateRequest che è assente se non richiede l'autenticazione client. L'output di s_client è simile al seguente:

<<< TLS 1.0 Handshake [length 0008], CertificateRequest
    0d 00 00 04 01 01 00 00

Non sono sicuro di come funzioni se il server utilizza l'autenticazione client solo su percorsi specifici, poiché l'handshake SSL iniziale è completo prima che il client trasmetta la richiesta HTTP. Sarebbe ragionevole per il server richiedere una nuova stretta di mano a questo punto, ma non ho mai testato per vedere quali server supportano questo.

Puoi falsificare una richiesta HTTP tramite s_client manualmente, inserendo:

GET /your/path/here HTTP/1.1[Enter]
Host: server.y.com:443[Enter]
[Enter]

Se non vedi mai un messaggio CertificateRequest, il tuo server non è impostato correttamente.

Specificare i vincoli di sicurezza basati sulla struttura delle directory è abbastanza comune e può effettivamente semplificare l'amministrazione della sicurezza. Non ti preoccupare se ti offre una soluzione.

403.7 non è un codice di stato HTTP. È che alcuni Microsoft "abbracciano, estendono ed estinguono" sotterfugio? In ogni caso, non sembra la giusta direzione da perseguire, poiché si tratta di un problema di livello di trasporto, non di un livello di applicazione.