Esiste un meccanismo per controllare quali certificati firmati sono non revocati?

2

Attualmente stiamo usando EasyRSA e OpenSSL per gestire i nostri certificati VPN utente per OpenVPN. Il processo che abbiamo al momento è:

  1. L'utente genera una CSR sul proprio laptop e la invia a noi per firmare
  2. Copiamo il CSR sul server, lo firmiamo e restituiamo il CRT firmato all'utente
  3. Di solito lasciamo una copia della CSR e della CRT sul server
  4. Quando il certificato di un utente viene revocato, archiviamo queste informazioni in un CRL

Ho il compito di controllare chi ha accesso alla VPN. Per quanto ne so, l'unico modo per controllare chi ha accesso è elencando tutti i CRT sul server e sottraendo i CRT revocati come elencati nel CRL. Tuttavia, questo mi sembra non del tutto sano, come se qualcuno avesse cancellato un CRT e una CSR dal server, non avremmo modo di sapere che era mai stato firmato.

Il metodo attuale è affidabile? In caso contrario, esiste un modo per sapere esattamente quali certificati sono stati firmati sono ancora validi?

    
posta zymhan 17.07.2014 - 16:02
fonte

2 risposte

4

I certificati sono per autenticazione , non per autorizzazione .

Autenticazione è (qui) sul server OpenVPN che si assicura che il presunto client sia chi dichiara di essere. Questo è il punto dei certificati: il cliente mostra il suo certificato, che contiene la sua chiave pubblica e identità; il server convalida il certificato (per quanto riguarda la sua CA attendibile) per assicurarsi che i contenuti del certificato siano autentici; il client dimostra la padronanza della chiave privata corrispondente (normalmente generando una firma basata su una richiesta del server - ciò avviene all'interno dei dettagli del protocollo di comunicazione). In questo modo, il server apprende che chiunque si trovi all'altro capo della linea è realmente il proprietario della chiave pubblica che si trova nel certificato client; e il certificato, verificato come autentico, consente al server di dedurre che l'identità nel certificato è in realtà quella del proprietario della chiave.

L'autorizzazione si verifica come un secondo passaggio. Ora che il server sa chi sta chiamando, deve comunque decidere se quel client deve avere accesso o meno. Questa è una decisione lato server.

Dalla tua descrizione, l'OpenVPN (apparentemente) configurato usa i certificati per l'autorizzazione; oppure, in caso contrario, si applica "un'autorizzazione automatica" che consente l'accesso a chiunque possa ottenere l'autenticazione. Questa è la radice del tuo problema; i certificati non sono buoni per l'autorizzazione. Come hai notato, se si utilizza tale regola di autorizzazione, gli "utenti consentiti" non possono essere elencati in modo affidabile, a meno che non si abbia conoscenza di tutti i certificati emessi. Inoltre, se desideri chiudere l'accesso per un utente, normalmente devi chiuderlo ora , non entro una settimana ; ma la revoca è asincrona e sarà effettiva solo quando il CRL precedente è scaduto.

Mentre una buona deve conservare una conoscenza precisa di tutti i certificati che ha emesso (se solo è in grado di revocare un certificato a volontà), non c'è alcun meccanismo in X.509 per assicurare coerenza e integrità di tale elenco. Inoltre, la natura asincrona della revoca è un'ulteriore prova del fatto che i certificati forniscono mezzi di autorizzazione inadeguati.

Quello di cui hai veramente bisogno è mantenere un elenco completo di "utenti consentiti" sul lato server (nei file di configurazione di OpenVPN). Gli utenti verrebbero identificati dal loro nome (apparentemente, OpenVPN utilizza la parte "Common Name" del subjectDN nei certificati per fare riferimento agli utenti); il server estrarrà l'identità del client dai certificati client in entrata e autorizzerà l'utente solo se appare nell'elenco degli utenti consentiti. Se si distribuisce tale autorizzazione esplicita, allora si ha un elenco affidabile di utenti consentiti poiché, per definizione, è l'elenco che il server OpenVPN utilizza per concedere o negare l'accesso. Inoltre, ti permette di bloccare e sbloccare l'accesso per ogni specifico utente istantaneamente .

    
risposta data 18.07.2014 - 15:52
fonte
0

Autorità di certificazione (host)

In breve, oltre alla risposta eccellente da Thomas Pornin

Il secondo passaggio sembra sbagliato:

Devi creare un host separato con account dedicato (idealmente non root e utilizzare meccanismi forti per garantire che l'utente root non abbia accesso ai dati segreti come la chiave privata di ca) . e non connesso a Internet! Quindi preoccupati degli scambi di dati con questo host!

Il meccanismo di firma CSR deve essere utilizzato da e per questa autorità di certificazione .

Prenditi cura anche dei backup: tienili crittografati e al sicuro!

    
risposta data 10.12.2015 - 15:20
fonte