VPN con certificato client tramite PKI gestita - da dove proviene la chiave privata?

Prendo una leggera ipotesi, tuttavia, sospetto che nel browser venga utilizzato generateCRMFRequest e importUserCertificate in combinazione. Una panoramica del processo è fornita dalla documentazione deprecata Javascript_crypto per Firefox.

È possibile ottenere risultati simili con Internet Explorer . Non ho guardato ma immagino che Safari abbia anche un certo livello di supporto.

Queste sono estensioni interamente non standard e secondo questo post nel forum CA / Browser , non il futuro.

La chiave è generata localmente, tuttavia, è difficile dire se la chiave sia inviata o meno alla CA per "archivio" come in generateCRMFRequest. Dal momento che il javascript ha accesso alla chiave generata, potrebbe in teoria inviarlo su Internet.

Informazioni finali, esiste uno strumento generico per farlo in Linux? Non a mia conoscenza. Puoi certamente passare attraverso:

openssl genrsa ... -out private.key
openssl req -new ... -inkey private.key -out certplease.csr

invio di certplease.csr alla CA. Da loro si otterrà un certificato PKCS # 7 firmato da loro (e possibilmente altri certificati nella catena, nel caso siano necessari).

Tuttavia, non credo che ci sia un archivio di chiavi private standard basato su utente in Linux - piuttosto, ogni ambiente desktop ne ha uno leggermente diverso.

Questa è una domanda affascinante.

Innanzitutto, alcuni pensieri sul file .cer che ottieni: Controlla l'elenco degli standard PKCS ; PKCS # 7 è solo un contenitore per il trasporto di dati firmati / crittografati, che non ci dice nulla su cosa potrebbero essere quei dati. Se i dati all'interno erano in formato PKCS # 12 , allora è del tutto possibile che la chiave privata fosse inclusa in essa. Immagino che la domanda importante sia: hai dovuto inserire una password come parte dell'importazione del .cer ?

PKI gestito da Symantec

Ci sono alcuni suggerimenti (ma nessuna risposta) in Servizio PKI gestito Symantec ™ Guida alle opzioni di distribuzione .

Stai descrivendo chiaramente

2.1.1 Native browser enrollment

The native browser enrollment requires no software to be installed on the end user’s computer, and works in both cloud and hybrid scenarios.

Anche se è piuttosto carente nei dettagli su dove viene generata la chiave.

Avere il server generare una chiave privata per te e raggrupparlo nel file .cer sarebbe coerente con frasi come questa:

... This option is important in terms of ensuring that high security certificates, such as a smart card or USB token, end up in the appropriate store.

Poiché i certificati sono, per definizione, pubblici, l'unico modo in cui la frase "certificati di sicurezza elevata" ha senso è se c'è una chiave privata in dotazione con esso.

Inoltre fanno molti riferimenti ai servizi di registrazione / gestione delle chiavi di Microsoft Active Directory. Ma questo non spiega il tuo caso Linux.

Modifica: Duh. Qualcos'altro che è possibile è che il browser abbia accesso alle funzionalità crittografiche del sistema operativo (ad esempio Microsoft CAPI ) e il javascript sul la pagina di registrazione ottiene il sistema operativo per creare una chiave privata e genera una richiesta di certificato che include una prova di possesso di quella chiave.

La chiave privata viene generata dal client che crea la richiesta di certificato. Quando il client importa il certificato, l'applicazione Keychain riconosce automaticamente che questo certificato è per quella chiave privata specifica.

Non sono sicuro di Symantec, ma Comodo pochi anni fa (~ 2012) usava keygen html5 per questo scopo. Il tag Keygen genera il formato SPKAC csr e l'interfaccia utente tipicamente (sulla pagina Web) contiene una casella a discesa con le lunghezze delle chiavi disponibili. link

Keygen è (era) supportato da firefox, chrome e opera, non è mai stato supportato da internet explorer.

In caso di opera12, dopo aver attraversato il modulo keygen, ma prima di ricevere il certificato, c'erano le chiavi private non collegate nel gestore certificati, che erano state generate per quel csr. (e se il certificato finale non arriva mai, quelle chiavi rimangono in gestione certificati per sempre). (scheda personale, in gestore certificati).

Non conosco i dettagli esatti su come viene gestito da firefox o chrome.

Una CA rilascia certificati digitali a entità e individui dopo aver verificato la loro identità. Firma questi certificati usando la sua chiave privata; la sua chiave pubblica è resa disponibile a tutte le parti interessate in un certificato CA autofirmato. Le CA utilizzano questo certificato radice affidabile per creare una "catena di fiducia": molti certificati radice sono incorporati nei browser Web in modo che abbiano fiducia integrata di tali CA. Server Web, client di posta elettronica, smartphone e molti altri tipi di hardware e software supportano anche PKI e contengono certificati di root attendibili dalle principali CA.

Un tipico PKI è costituito da hardware, software, criteri e standard per gestire la creazione, l'amministrazione, la distribuzione e la revoca di chiavi e certificati digitali. I certificati digitali sono al centro di PKI in quanto affermano l'identità dell'oggetto del certificato e collegano tale identità alla chiave pubblica contenuta nel certificato.

Una PKI tipica include i seguenti elementi chiave:

• Una parte fidata, chiamata autorità di certificazione (CA), funge da radice della fiducia e fornisce servizi che autenticano l'identità di individui, computer e altre entità

• Un'autorità di registrazione, spesso chiamata CA subordinata, certificata da una CA radice per emettere certificati per usi specifici consentiti da root

• Un database di certificati, che memorizza richieste e problemi relativi ai certificati e revoca i certificati

• Un archivio certificati, che risiede su un computer locale come luogo archivia i certificati emessi e le chiavi private

Insieme alla chiave pubblica di un'entità o di un individuo, i certificati digitali contengono informazioni sull'algoritmo utilizzato per creare la firma, la persona o entità identificata, la firma digitale della CA che ha verificato i dati sull'oggetto e ha emesso il certificato, lo scopo di la crittografia a chiave pubblica, la firma e la firma del certificato, nonché un intervallo di date durante il quale il certificato può essere considerato valido.