Come convalidare un certificato client

Da una prospettiva di alto livello, devono accadere tre cose:

1. Il client deve dimostrare di essere il proprietario appropriato del certificato client. Il server Web sfida il client a firmare qualcosa con la sua chiave privata e il server Web convalida la risposta con la chiave pubblica nel certificato.

2. Il certificato deve essere convalidato rispetto all'autorità di firma. Ciò è possibile verificando la firma sul certificato con la chiave pubblica dell'autorità di firma. Inoltre, gli elenchi di revoche di certificati (CRL) vengono controllati per garantire che il certificato non sia stato inserito nella lista nera.

3. Il certificato deve contenere informazioni che lo designano come utente valido del servizio web. Il server Web è configurato per esaminare specifici elementi nel certificato (in genere il campo dell'oggetto) e consentire solo determinati valori.

Lo standard è chiamato "X.509" ed è meglio conosciuto sotto la sua incarnazione come "Profilo X.509 Public Public Infrastructure Certificate and Certificate Revocation List (CRL)", meglio conosciuto come RFC 5280 . L'algoritmo di convalida completo, standard, è presentato in dettagli dettagliati (dolore) in sezione 6 .

Non ci si può aspettare di capire seriamente come funziona X.509 finché non si è passati allo sforzo di leggere quel documento almeno una volta. Sarà un problema, ma questo perché certificati e PKI sono una questione intrinsecamente complessa, che richiede nozioni molto precise su identità, autenticazione, chiave privata e affidabilità. X.509 cerca di affrontare questa complessità in anticipo, portando a standard come Behemoth come RFC 5280.

Contrassegnare la chiave privata come "non esportabile" è solo un pio desiderio; rende leggermente più difficile per gli utenti non tecnici esportare effettivamente la propria chiave. Una risposta migliore sarebbe che non dovrebbe importare . Un utente autentica se stesso dimostrando il suo controllo sulla chiave privata associata al suo certificato. Se l'utente vuole archiviare la sua chiave privata altrove, è affar suo; nello stesso modo in cui non importa se inserisci la chiave della porta nella tasca dei pantaloni sinistra o nella tasca dei pantaloni destra . E, allo stesso modo, se lasci la chiave della porta sotto lo zerbino e alcuni individui ingannevoli la prendono da lì, allora la tua sicurezza scompare, ma la tua compagnia assicurativa ti farà notare che è colpa tua.

I certificati possono contenere una varietà di parametri che possono essere utilizzati per limitare l'uso del certificato. Ad esempio, un certificato può essere rilasciato con nome dell'applicazione e nome utente, quindi l'applicazione può confermare che il certificato è valido per la particolare applicazione, quindi eseguire la convalida del certificato x.509 standard e quindi limitare le credenziali utente accettabili a quelle dell'individuo a chi è stato rilasciato il certificato.

Si tratta di un solido utilizzo di certificati lato client che richiede che la ditta che pubblica l'applicazione specifichi e / o controlli l'emissione dei certificati e che l'autenticazione basata su certificato sia terminata o passata allo stesso livello architettonico che autentica le credenziali dell'utente. [In altre parole, i concentratori SSL / TLS possono causare problemi.]

NOTA: i campi aggiuntivi nel certificato sono protetti da crittografia in modo che, mentre sono visibili, non possano essere modificati senza distruggere la validità del certificato. Di conseguenza, l'inclusione di questi parametri non può essere falsificata con meno difficoltà rispetto allo spoofing dell'intero certificato.

RIFERIMENTI

• Una domanda direttamente correlata - Aggiunta di dati personalizzati in X.509 certificato
• Guida Microsoft -
  link
• Articolo di Wikipedia -    link

Prima di tutto penso davvero che sia necessario identificare cosa sta succedendo esattamente con la certificazione della chiave privata:

1. Chiave privata: questo è qualcosa che devi tenere segreto, solo per i tuoi occhi.
2. Chiave pubblica: questo è qualcosa che gli utenti useranno in modo che possano contattarti (è come se tu stessi usando una lingua che solo il proprietario della chiave privata conosce).
3. Certificato: questo è qualcosa per verificare che la chiave pubblica sia effettivamente quella associata al proprietario della chiave privata.

Quindi, considera che un certificato è qualcosa di pubblico che puoi regalare senza preoccuparti di ciò.

Come funziona un certificato? Consentitemi di metterlo in parole semplici: quando rilasciate una chiave pubblica, la CA aggiunge un "segno segreto" al certificato, quindi quando volete convalidarlo dovete inviare il certificato dal proprietario alla CA in modo che possa verificare se la "parte segreta" è ok. Se la CA controlla la parte segreta ed è coerente, ti darà il "OK" per usare la chiave pubblica, se non dovresti essere sospettosa di usarla.

Considera di dare un'occhiata a questo diagramma di wiki in modo da poter conoscere l'intero processo di creazione e convalida (incluso CA):

link

Anche questo altro diagramma potrebbe essere utile:

link

Inoltre, considera che le CA sono in genere agenzie di fiducia ben note e normalmente i browser hanno un elenco di esse incluse. Ma alcune entità (in genere agenzie o organizzazioni pubbliche) utilizzano la propria CA e la si deve aggiungere manualmente all'elenco (si prega di essere estremamente cauti in merito, poiché una CA dannosa potrebbe davvero compromettere le comunicazioni).

Spero che questo ti aiuti.

(Sentiti libero di aggiungere qualsiasi correzione di grammatica / sintassi poiché l'inglese non è la mia lingua madre).

Diversi progetti, come pathfinder-pki , ti permetteranno di convalidare i certificati in modi pienamente conformi.