Una risposta alla domanda 1:
Sì, tranne che la root della CA non è in linea in un HSM in un vault, non disponibile per essere rubato elettronicamente. La root è stata utilizzata per firmare una manciata di certificati intermedi (backup e certificati di risponditore OCSP e altre informazioni) che risiedono in HSM direttamente connessi ai computer che possono essere raggiunti elettronicamente.
Per emettere un certificato, il "back-end" della CA:
- riceve CSR
- utilizza alcuni metodi di convalida (protocollo ACME, clic umani "ok" sul sito web di amministrazione, ecc.)
- registra tutte le decisioni e le informazioni utilizzate per prendere la decisione per il controllo con un controllo successivo
- genera i dati del certificato (X.509 v3) codificati in DER X.690, utilizzando un modello e un nuovo numero di serie / fonte di casualità.
- forse ottiene gli SCT della trasparenza del certificato
- chiede all'HSM di firmare il blob (o l'hash del blob).
- aggiunge la firma al certificato e la invia allo spazio di archiviazione del cliente.
Una risposta alla domanda 2:
Nello scambio di chiavi RSA, il client genera una sequenza casuale di byte ed esegue la crittografia RSA utilizzando la chiave pubblica dal certificato del server. Quindi il client invia il testo cifrato risultante al server e si aspetta che il server lo decodifichi (utilizzando la chiave privata corrispondente alla chiave pubblica dal certificato) e utilizzi il valore casuale in un KDF, insieme ad altri valori, per generare chiavi simmetriche e invia un messaggio finito crittografato con le chiavi simmetriche risultanti. Il client verifica il messaggio Finito. Il server può solo riuscire a generare le chiavi simmetriche attese tramite messaggio crittografato RSA di decifratura. link
Nello scambio di chiavi DHE / ECDHE con PFS, il server firma la sua chiave temporanea utilizzando la chiave privata corrispondente alla chiave pubblica nel certificato e la invia in ServerKeyExchange. Il client verifica la firma utilizzando la chiave pubblica dal certificato. link
Una risposta alla domanda 3:
Il browser contiene un elenco di root attendibili (Mozilla Firefox fa ciò) o utilizza un elenco di root attendibili forniti dal sistema operativo (Google Chrome utilizza il root store del sistema operativo). L'archivio radice contiene certificati autofirmati e alcuni metadati su di essi che potrebbero limitare ciò per cui possono essere utilizzati. I browser contengono anche codice che aggiunge controlli aggiuntivi, come Chrome che richiede la trasparenza dei certificati dalle CA di proprietà di Symantec e le date limite che consentono l'utilizzo dei certificati SHA1.
Il modo in cui un server foglia / certificato di dominio viene verificato utilizzando l'archivio principale è creando una catena di certificati intermedi, uno firmando l'altro, da una radice attendibile all'anta. La radice firma un intermedio e l'intermedio firma la foglia. Ci può essere più di un intermedio in una catena. Gli intermedi vengono inviati dal server insieme alla foglia.
link
Diversi computer hanno diversi archivi root e utilizzando la cross signing, possono essere creati molti percorsi diversi. Attualmente i browser tentano di costruire percorsi sha256-only, se possibile, a volte falliscono e producono un errore dicendo che solo un percorso sha1 è stato creato, quindi la connessione potrebbe essere insicura.
Non confondere le firme digitali con la crittografia: link