perché il primo certificato ha una chiave pubblica RSA in x.509?

La chiave pubblica contenuta in un certificato può essere utilizzata in due modi:

• Viene utilizzato per decrittografare qualcosa che è stato crittografato con la chiave privata corrispondente (in genere per verificare una firma)
• Viene utilizzato per crittografare qualcosa che sarà "decrytable" solo con la corrispondente chiave privata

C'è un gran numero di certificati sul Web, quindi per fidarci di loro, usiamo "Autorità di certificazione" di terze parti. Hai un elenco di certificati CA affidabili installati nel tuo browser. L'obiettivo principale di questi certificati è di firmare altri certificati, per dimostrare che sono validi (se qualcuno di cui ti fidi ti dice che un'altra persona è affidabile, ti fidi dell'altra persona - questa è la logica comunque).

Ecco perché utilizziamo la chiave pubblica del secondo certificato nell'esempio per verificare la firma del primo certificato. Ma utilizzerai questo certificato per qualcosa (crittografia, firma, ecc.), E questo è il momento in cui avrai bisogno della chiave pubblica del certificato.

In crittografia asimmetrica:

• La chiave privata viene utilizzata per firma e decifratura / decrittografia .
• La chiave pubblica viene utilizzata per verifica delle firme e codifica / crittografia .

Vedi il glossario delle specifiche TLS :

public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.

Nel tuo esempio, utilizzi effettivamente la chiave pubblica del secondo certificato (un certificato CA) per verificare la firma del primo certificato (un certificato di entità finale).

Tuttavia, questo passaggio stabilisce solo la fiducia nel certificato stesso. Come utilizzerai la chiave pubblica di quella EEC dipenderà da cosa è usato.

Quando il certificato viene presentato dal server in SSL / TLS, la chiave pubblica verrà utilizzata come parte dell'handshake per dimostrare che il server remoto ha effettivamente la chiave privata per il certificato che sta utilizzando. Che sia usato per crittografare o verificare una firma dipende dai dettagli della suite di crittografia utilizzata durante questa connessione, in particolare, dipende da RSA o Diffie-Helman (autenticato) scambio di chiavi .

Un punto chiave dell'handshake TLS è stabilire un segreto pre-master condiviso tra client e server. Quando si utilizza lo scambio di chiavi RSA, il client crittografa il pre-master-secret e lo invia al server (che è l'unico in grado di decrittografarlo). Quando si usa DH, il client verifica la firma dei parametri temporanei inviati dal server durante lo scambio DH: il risultato finale è anche un pre-master-secret condiviso. Il risultato finale è lo stesso, però. Se vuoi davvero capire la differenza tra questi due approcci, probabilmente dovrai leggere la specifica TLS in dettaglio.

Altri protocolli e applicazioni possono utilizzare il certificato X.509 (ad esempio, firma / crittografia e-mail con S / MIME). La chiave pubblica nel certificato verrà sempre utilizzata per uno di:

• crittografia di un dato che può essere decodificato dall'entità identificata da questo certificato (cioè il legittimo proprietario della chiave privata corrispondente).
• verifica che un dato sia stato firmato da questa entità.

I dettagli su cosa sia quel dato e come vengono utilizzati variano a seconda del protocollo e dell'applicazione.

In questo particolare esempio, l'uso del certificato e della coppia di chiavi FreeSoft è sconosciuto. Sarà presumibilmente usato per qualcosa, ma l'esempio e il certificato non chiariscono cosa potrebbe essere quel "qualcosa".

Il certificato FreeSoft è un certificato di entità finale, in quanto l'uso della chiave NON include l'estensione che la contrassegnerebbe come un'autorità di certificazione. Quindi, la coppia di chiavi aiuterà, in qualche modo, il portachiavi (FreeSoft) a svolgere una sorta di compito, generalmente:

• firma - prova che proviene dal portachiavi e non è stato manomesso

• crittografia - protezione che garantisce che i dati inviati al titolare della chiave non vengano manomessi o visualizzati durante il transito

• autenticazione - prova che il portachiavi è chi dice di essere perché detiene una chiave privata che non è condivisa ovunque

O una grande varietà di permutazioni più sottili di questo.

Ma - in questo esempio, è impossibile dire cosa, esattamente.

In tutta praticità, avrei difficoltà a capire cosa fare con questo certificato, dovrei farlo rielaborare per renderlo utile, dato che la maggior parte delle applicazioni standard richiedono un qualche tipo di utilizzo chiave descritto all'interno del certificato. Come mostrato, questo certificato non ha un utilizzo chiave, quindi è abbastanza inutile.

Credo che in questo caso, si inserisce nel difetto di essere un esempio per un punto specifico (hiearchy certificato) con poca riflessione data alla completezza.