Autenticazione client SSL / TLS - Pratica validazione del cert client

Question

Autenticazione client SSL / TLS - Pratica validazione del cert client

#1 da (2 voti)
#2 da (-1 voti)

2

In che modo i server HTTPS reali convalidano i certificati client? Il mio contesto è business-to-business piuttosto che normali clienti umani. Comprendo la convalida della catena di base a un certificato CA radice affidabile. Ma i server hanno in genere una sorta di configurazione per specificare i nomi dei soggetti di cui si vogliono fidare, o i valori delle impronte digitali?

In uno scenario, una CA privata che agisce per conto del server può firmare i certificati client in modo tale che SOLO i loro certificati siano accettati. In un altro scenario, il server considera attendibili i certificati firmati da qualsiasi CA "normale" attendibile (scelta del cliente) nel proprio archivio sicuro. Ma se il tuo sistema deve essere chiuso (come in un caso business-to-business), allora vuoi un ulteriore filtro.

Mi rendo conto a livello di applicazione se la catena di certificati è disponibile, quindi è possibile qualsiasi ulteriore filtraggio personalizzato. Ma voglio solo sapere nel mondo reale, immediatamente, quali server web di configurazione aggiuntivi devono occuparsi di questo oggi durante l'handshake TLS.

Grazie.

authentication client tls

posta Harry 20.05.2015 - 22:34

fonte

2 risposte

Leggi altre domande sui tag authentication client tls

Metodi per la firma immediata del certificato Utilizzare la chiave del server per firmare digitalmente il contenuto HTML consegnato?

score 2 · Answer 1

Quando il server utilizza IIS, l'autenticazione client significa mappare il certificato client a un'identità , ovvero un account (account locale o account di dominio, a seconda del contesto). IIS può applicare due metodi distinti, con nomi confusi:

clientCertificateMappingAuthentication : IIS sembrerà per un account di dominio che contiene una copia del certificato client esatto o almeno un account di dominio di cui attributo User-Principal-Name corrisponde a quello contenuto nel certificato (come Subject Alt Name di tipo otherName , identificato con un OID specificato da Microsoft). L'uso di UPN è soggetto ad alcune condizioni arcane, inclusa l'archiviazione di una copia del certificato CA immediatamente emittente ( non CA principale) nell'archivio certificati "enterprise NTAuth" del computer server IIS o del server AD o forse entrambi. Puoi usare questa pagina del blog per qualche consiglio.
iisClientCertificateMappingAuthentication : questo ha due sotto-metodi, quella documentazione di IIS chiama "mapping one-to-one" e "mapping many-to-one". Nel mapping one-to-one, la configurazione di IIS contiene associazioni esplicite da un certificato esatto (il certificato completo in Base64) a un account (locale o dominio). Nel mapping many-to-one, la configurazione contiene alcune regole che corrispondono fondamentalmente a parti di IssuerDN e SubjectDN e mappano esplicitamente i certificati corrispondenti a un determinato account.

Nel mondo non Microsoft, nel server Web Apache, useresti SSLRequire per implementare le regole di accesso, in base agli elementi estratti dal certificato (in pratica, IssuerDN e SubjectDN).

Ciò che deve essere ricordato è questo:

I certificati sono per autenticazione , non per autorizzazione . Il primo riguarda l'accertamento di chi sta chiamando, il secondo di decidere se consentire a quel determinato cliente di eseguire l'accesso richiesto. Il modello IIS è autorizzato principalmente con i diritti di accesso: una volta che il certificato è stato mappato su un account, il resto è roba specifica per l'AD senza più relazioni con i certificati; questo potrebbe essere un semplice diritto di accesso ai file, o probabilmente una configurazione di autorizzazione più dettagliata con AzMan o qualsiasi altra sostituzione nelle ultime versioni di Windows.

Provare a fare l'autorizzazione con i certificati (ad esempio, emettere certificati client che contengono alcune informazioni come "può fare l'operazione X") di solito finisce con le lacrime e la digrignazione dei denti. Per tutto il suo clunkiness, il metodo Microsoft ha il merito di separare chiaramente l'autenticazione e l'autorizzazione.
Esiste sempre una fase di convalida del certificato, che garantisce che il certificato sia autentico e accettabile. Ciò include la verifica di tutte le date, le firme crittografiche, il nome del concatenamento, lo stato di revoca ...
Potrebbe esserci un filtro aggiuntivo sui percorsi, come quello che fa IIS quando si utilizza il mapping dei certificati client basato su UPN: la presenza della CA di emissione nell'archivio NTAuth aziendale funge da controllo aggiuntivo che rifiuta i percorsi dei certificati che sono validi, provengono da una radice accettata, ma non sono passati attraverso la CA intermedia prevista.

score -1 · Answer 2

Non sono sicuro che ci sia una soluzione. Diverse strategie funzionano per l'implementazione di diverse funzionalità.

Una strategia comune per un'implementazione B2B è che l'organizzazione del server agisca come CA e firmi le chiavi pubbliche dai client. Quando viene ricevuto un certificato cliente, il server convalida la firma e quindi associa il certificato a un utente. Il mapping degli utenti viene in genere eseguito estraendo un campo dal certificato, ma è anche possibile utilizzare una ricerca CERT o un'altra strategia.

Il modo in cui implementa questa convalida e la mappatura dipenderà dal server che stai utilizzando.

Una cosa a cui prestare attenzione è che puoi fidarti solo dei certificati client che sono stati usati in un handshake di mutuo autenticazione SSL. Non lasciare che il cliente ti passi il loro certificato. È necessario ottenerlo dal sottosistema SSL per assicurarsi che sia stato convalidato (ovvero: il client ha dimostrato di possedere la chiave privata corrispondente al certificato).