Best practice per la progettazione di catene di certificati TLS mutuo-auth?

Vorrei implementare una semplice gerarchia a due livelli con una singola CA principale e una singola emittente che emetterà certificati per entrambi, client e server. A meno che non esistano requisiti specifici, non è necessario distribuire più root o anche CA intermedie. Mantieni semplice il livello 2.

do I have to provide root cert to all?

Sì. I client dovranno fidarsi della tua root per autenticare il server. Il server dovrà fidarsi della tua root per autenticare i client.

What happens if one of the devices get compromised? (Revoking?)

Sì. Tuttavia, la revoca potrebbe avere una grande latenza. Pertanto potrebbe essere ragionevole avere un database locale per registrare tutti i client e le loro informazioni di base. Se il dispositivo viene compromesso, aggiorna il database (disabilita l'account del dispositivo) per impedire temporaneamente il collegamento del dispositivo al server fino a quando il problema non viene risolto.

Non so se esiste un singolo set di "best practice" per fare client-auth poiché dipende molto dai dettagli del proprio ambiente. Probabilmente puoi trovare le migliori pratiche per configurare un'autorità di certificazione per l'autenticazione del client VPN, se è abbastanza vicino.

Posso darti una lista di domande a cui dovresti pensare nel contesto della tua applicazione. Nel risolvere questi problemi, la domanda sulla gerarchia CA può essere risolta per te.

• C'è qualcosa che distingue un client da un server? Sarebbe male se qualcuno potesse creare un server falso usando un certificato cliente e ottenere altri client per connettersi ad esso. Esistono diversi modi per risolvere questo problema: è possibile utilizzare CA radice diverse per client e server, anche se potrebbe essere più semplice inserire un "I am a client" e "I am a server" Utilizzo chiavi estese nel certificato. Nota che i metodi più intelligenti richiederanno di scrivere codice di convalida del certificato personalizzato sul client e / o sui componenti del server.

• Come funziona la revoca? Se un client / server ha bisogno di revocare il certificato, chi viene a contatto? Come sapranno i server / clienti che è stato revocato? Con che velocità i server / client sanno che è stato revocato?

• Come si aggiornano i certificati client quando scadono? (non tirare un Tesla , completo thread Twitter qui )

• Come stai proteggendo le chiavi private delle CA? Vengono memorizzati su una sorta di token hardware? Cosa succede se le macchine che ospitano le CA scendono? (temporaneamente, bloccando le informazioni di revoca dalla pubblicazione o permanentemente, perdendo le chiavi private della CA)

Fondamentalmente, penso che la configurazione della gerarchia della CA finisca per essere un effetto collaterale di come si affrontano le altre considerazioni sulla sicurezza;)