Quello che sto cercando di archiviare è abilitare i codici ECDSA e DSS nel mio sito, ma allo stesso tempo non dipende solo dai certificati autofirmati, quindi potrei inviare al mio cliente più di un certificato e loro potrebbero selezionare ECDSA e DSS su RSA se possono verificare il mio certificato autofirmato e, in caso contrario, ricorrere a un certificato firmato da una CA e rifiutare ECDSA e DSS.
In senso stretto, il server può inviare un numero arbitrario di certificati al client, come parte del suo messaggio Certificate . Tuttavia, come lo standard dice :
The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it.
Pertanto, un server veramente conforme non può inviare una scelta di certificati al client e non può aspettarsi che i client utilizzino altri certificati rispetto al primo che inviano.
Per il supporto dell'algoritmo della firma , esiste un'estensione TLS standard specificata in sezione 7.4.1.4.1 , con cui il client può comunicare al server, all'inizio della stretta di mano (in ClientHello , che è il primo messaggio della procedura) , quali funzioni hash e algoritmi di firma supportati. Ciò consente a un server che possiede, ad esempio, sia un certificato firmato da RSA che un certificato firmato da ECDSA, di inviare uno o l'altro, a seconda di ciò che il client supporta. Questo è tipico di come vanno le cose in TLS: il client suggerisce, il server sceglie.
(In pratica, il supporto per questa estensione non è ancora diffuso, ma, anche nella pratica, tutti usano RSA e supportano RSA.)
Leggi altre domande sui tag tls certificates certificate-authority cipher-selection