Il server invia il suo certificato durante TLS handshake
e il client verifica il suo percorso di fiducia.
Nel primo passaggio il client corrisponde al campo del nome comune (CN) con il nome host del server (non confronta i certificati).
Quindi il client verifica il percorso di fiducia, ovvero se il certificato presentato dal server è firmato da un'entità il cui certificato si trova nell'archivio dei certificati radice attendibili (di nuovo: non corrisponde direttamente al certificato)
- se si utilizza un certificato autofirmato e lo si aggiunge all'archivio, la verifica viene eseguita correttamente quando il certificato del server si trova nello stesso archivio;
- se si utilizza una CA (autofirmata), la verifica ha esito positivo, quando si firma il certificato di CA è nell'archivio attendibile del client.
Does it loop through all the certificates from its store and get the one matching with the SQL Server's certificate?
Ricordare che il client non sta tentando di abbinare i due certificati (inviati dal server e memorizzati sul client), ma per verificare il certificato utilizzato per firmare il certificato inviato.
Per quanto riguarda il processo stesso, puoi pensarlo in questo modo, ma se esso controlla il percorso di fiducia eseguendo il looping di tutte le voci o utilizza un indice per accelerare il processo, è un dettaglio di implementazione che non interessa realmente utente.
Is there any way to configure the client to use XXXX certificate for the SQL Server 1 and YYYY certificate for the SQL Server 2?
Il client verificherà la fiducia del certificato inviato dal server durante la fase di handshake. In modo efficace saranno diversi per SQL Server 1 e SQL Server 2 e funzioneranno come descritto senza alcuna configurazione aggiuntiva.
Come sidenote, non dovresti gestirlo davvero aggiungendo un certificato autofirmato per ogni server separatamente, ma crea una CA e firma i certificati di sever usando questo. Quindi distribuisci un solo certificato CA a tutti i client.