Che cosa è un certificato SSL destinato a dimostrare e come lo fa?

La tua teoria delle chiavi: fondamentalmente corretta, ma l'autenticazione viene solitamente eseguita crittografando un hash crittograficamente sicuro dei dati piuttosto che i dati stessi.

La firma di una CA su un certificato SSL dovrebbe indicare che la CA ha svolto una certa quantità di diligenza per garantire che le credenziali del certificato corrispondano al proprietario. Quella diligenza varia, ma il punto finale è che stanno dicendo che il certificato che hanno firmato appartiene all'entità chiamata su di esso.

Vedi link

Un certificato di chiave pubblica è la combinazione firmata tra una chiave pubblica, identificatori ed eventualmente altri attributi. Coloro che firmano questo documento effettivamente affermano l'autenticità del legame tra la chiave pubblica e l'identificatore e questi attributi, nello stesso modo in cui un'autorità emittente del passaporto asserisce il legame tra l'immagine e il nome in un passaporto, come vari altri pezzi di informazioni (nazionalità, data di nascita, ...).

In primo luogo, un paio di chiarimenti sulla terminologia:

• In senso stretto, non esiste un "certificato SSL". La maggior parte delle volte, questa è un'espressione breve per "certificato X.509 utilizzato per SSL / TLS". (SSL / TLS è anche in grado di utilizzare altri tipi di certificati come certificati OpenPGP , anche se questo è meno comune.)

• Il tuo uso di "crittografia" e "decrittografia" non è corretto qui. Nella crittografia a chiave pubblica:

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

  Consulta il glossario della specifica 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.

  Potrebbe non sembrare che questa distinzione nella terminologia sia importante, perché queste operazioni sono approssimativamente le stesse per quanto riguarda RSA (in realtà troverai routine sottostanti chiamate RSA_private_encrypt in OpenSSL), ma (a) questo non sarebbe lavorare per DSA e (b) non capire questa differenza fondamentale può portarti a commettere errori per quanto riguarda il tuo schema di sicurezza generale.

  In particolare, lo scopo della crittografia è nascondere qualcosa. Quando parli di "crittografia con una chiave privata" qui, non ha alcun senso poiché la chiave pubblica è nota a chiunque. Inoltre, la chiave pubblica dell'emittente non è obbligata a guardare all'interno di un certificato che questo emittente ha firmato, perché tutto (vedi TBSCertificate structure ) è chiaro che chiunque può vederlo comunque. Niente è nascosto qui.

  (Ciò che viene fatto per la firma con RSA è in effetti più o meno la stessa operazione della crittografia, ma con la chiave privata, applicata a un digest crittografico del messaggio da firmare, tipicamente fatto usando SHA-1 per i certificati al giorno d'oggi.)

Ciò che il certificato del server deve dimostrare è che la CA ha in qualche modo verificato l'associazione tra il nome host e la richiesta di certificato (in particolare, la chiave pubblica nella richiesta di certificato). Per lo meno, avrebbe il proprietario del nome di dominio tramite e-mail (per i certificati convalidati dal dominio). (Vedi le distinzioni tra le modalità di convalida qui .)

Il contenuto del certificato rilasciato deve essere conforme a RFC 3280 / RFC 5280, che definisce come i client devono verificare e convalidare il certificato. Questo definirà quali attributi possono essere usati, in particolare (estesi) gli attributi di utilizzo delle chiavi di solito, ad es. "Server TLS".

Di conseguenza, il certificato del server X.509 si legherà insieme:

• Una chiave pubblica (per la quale hai la chiave privata).
• Nome di un emittente (il DN oggetto del certificato CA)
• Un nome server (in conformità con RFC 2818 Sezione 3.1 o RFC 6125), nell'estensione Nome soggetto alternativo o nel Nome comune del Nome distinto soggetto.
• Estensioni di utilizzo.
• Eventualmente altre estensioni (critiche o meno), ad es. Norme sui certificati EV.

Questo è tutto inserito nella struttura TBSCertificate del certificato X.509. Poi questo la struttura viene digerita utilizzando un algoritmo di hash crittografico (ad esempio SHA-1) e firmata utilizzando la chiave privata della CA per formare la firma ( signatureValue nel risultante Certificate ).

Quando viene utilizzato il certificato, il client può verificare questa firma (utilizzando la chiave pubblica della CA che conosce o costruendo un percorso di certificazione utilizzando più certificati CA su uno degli ancoraggi di trust che conosce), verificare che gli attributi di utilizzo siano compatibile con l'utilizzo di SSL / TLS e verificare che il nome host richiesto corrisponda a quello per cui è stato rilasciato.

Va sottolineato, insieme a tutte le altre risposte, che la tua chiave privata non è sempre solo una chiave usata sia per decifrare che per firmare i messaggi. Questi dovrebbero essere due chiavi separate. Questo creerebbe 4 chiavi per ogni persona:

Chiave di crittografia pubblica : utilizzata per crittografare i dati da inviare a me.

Chiave di decrittazione privata : utilizzata per decrittografare i messaggi crittografati con la mia chiave di crittografia pubblica.

Chiave di firma privata : utilizzata per firmare i messaggi che invio ad altre persone.

Chiave di verifica pubblica : utilizzata per verificare che un messaggio sia stato, di fatto, firmato da me.

Ci sono alcuni motivi per usare chiavi separate per questo. Vedi questa discussione per maggiori dettagli.