Questa spiegazione spiega come funzionano le firme dei certificati SSL?

L'hash per la firma di un determinato cert è fisso, ma a un server è permesso avere più di un certificato, e così anche un client. TLS1.2 aggiunge un'estensione ciao che consente al client di specificare quali algoritmi di firma possono gestire, come coppie di hash + PKC come SHA256 + RSA o SHA384 + ECDSA; il server dovrebbe scegliere e inviare un certificato adatto se ne ha uno. Se non ha un certificato che il client può gestire, troppo male - a meno che il client e il server non siano entrambi d'accordo con una ciphersuite "anonima" che non richiede alcun certificato, che è insicuro contro l'attacco attivo e quindi di solito proibito.

Allo stesso modo se il server richiede un certificato client o un'autenticazione client, il che è raro, in 1.2 specifica algoritmi di firma accettabili e il client dovrebbe scegliere di conseguenza. Per tutte le versioni il client (anche) deve considerare l'elenco di CA accettabili specificate dal server, a meno che il server abbia scelto di lasciare vuoto quell'elenco, il che è ancora più raro.

Inoltre, il server non invia direttamente informazioni su cosa "supporta". ServerHello sceglie esattamente una ciphersuite e un algoritmo di compressione, dagli elenchi offerti da ClientHello. Se si utilizza ECC, il Cert successivo e possibilmente ServerKeyExchnage selezionano una curva e un formato punto tra quelli offerti. Non ci sono informazioni su altre suite, compressioni, curve o punti che il server supporta e potrebbe utilizzare in risposta a un ClientHello diverso. Il server sceglie anche una versione di protocollo nell'intervallo offerto dal client; se il server sceglie al di sotto del massimo del client, è una scommessa sicura che il server non supporta più alto, ma se è d'accordo con il massimo del client, potrebbe benissimo supportare più alto. Contrasto con SSH dove entrambe le parti inviano liste complete e calcolano l'intersezione; ma SSH normalmente non usa affatto i certs, solo publickey spogli.

In effetti non esiste una negoziazione, ma la citazione è ancora per lo più corretta.

Il certificato è semplicemente statico. Se hai installato il file del certificato e openssl, puoi vedere esattamente ciò che contiene con questa riga di comando:

openssl x509 -in <crtfile> -noout -text

Le stesse informazioni sono disponibili anche nei browser Web, ma devi essere un po 'attento; usare openssl è meglio. Ciò che il browser Web mostra non è così grezzo come quello che openssl mostra e il browser Web aggiungerà alcune informazioni aggiuntive derivate dal certificato. In particolare, è possibile visualizzare sia un'impronta digitale SHA1 che una SHA256 - non confondersi, quelli non si trovano nel certificato stesso.

Quando si guarda la firma all'interno del certificato, di solito si vede solo una firma, che ovviamente sarà quella che viene utilizzata - se il client non supporta quell'algoritmo di firma, non c'è nulla che possa essere d'accordo su, e questa è la fine di esso. Se il client lo supporta, può immediatamente iniziare a utilizzare quel certificato.

È anche immaginabile che un certificato contenga diverse firme usando algoritmi diversi (anche se non credo che il formato del certificato lo supporti effettivamente, questa idea sarebbe solo teorica), ma anche allora, lo stesso sarebbe valido ancora.

Quindi, la "negoziazione" consiste fondamentalmente nel server che invia il certificato con l'algoritmo della firma e dice al cliente "eccolo, prendilo o lascia".