La richiesta di certificato viene generata dove viene generata la chiave privata ; e la chiave privata dovrebbe, normalmente, essere generata dal client, poiché il client lo memorizzerà definitivamente.
Puoi avere un modello in cui tu (come un server) generi le chiavi per i client e poi distribuisci le chiavi e i certificati ai client, ma solleva la questione del perché usi i certificati del client primo posto: i certificati sono per situazioni in cui il prover (il cliente, che vuole essere autenticato) dimostra la sua identità al verificatore (il server) senza fornire sufficienti informazioni al verificatore per consentirgli di impersonare il prover in seguito quando parla con un terzo festa. In una classica configurazione client / server, questo è eccessivo; e questa proprietà extra scompare se il server stesso conosce le chiavi private (anche in modo transitorio).
Inoltre, la CA di terze parti ti farà sanguinare pagando la fatturazione per ogni certificato del cliente. L'utilizzo di una CA di terze parti per un'azienda puramente privata (i certificati client sono per te, non per chiunque altro) sembra denaro sprecato. Per il certificato server , ciò è comprensibile: si desidera un certificato che ogni potenziale cliente riconoscerà come valido, cioè rispetto a un certificato CA radice che già hanno. Ma nella direzione opposta, questo è solo il tuo server. La tua CA (ad es. Con EJBCA ) probabilmente varrebbe la pena.
Supponendo che l'utilizzo del certificato client sia una caratteristica inevitabile della situazione (ad esempio alcuni manager di alto livello hanno sentito il termine "certificato" e se ne sono innamorati), allora puoi produrli sul lato server parlando a DigiCert (o alla tua CA, se ne esegui una) con qualsiasi metodo appropriato per loro. Su un sistema Windows, la generazione di chiavi private, la creazione di richieste di certificati e l'accettazione del certificato risultante possono essere eseguite con lo strumento da riga di comando certreq . Una volta che hai la chiave privata (non ha mai lasciato la tua macchina) e il certificato, esportali entrambi come un archivio PKCS # 12 (chiamato anche "PFX"), protetto da una password e invialo al client, che li importerà nel suo browser. Naturalmente questo trasferimento dovrebbe avvenire con una certa protezione ... sebbene un archivio PKCS # 12 sia sufficientemente ben protetto dalla password, è comunque necessario trasferire la password all'utente in qualche modo.
