Qualcuno potrebbe spiegarmi la differenza tra questi certificati in modo semplificato? Ho letto alcuni articoli ma sembra che facciano lo stesso lavoro, vale a dire la crittografia di molti domini con un certificato.
Risposte:
SAN (Subject Alternative Name) fa parte delle specifiche del certificato X509 , in cui il certificato ha un campo con un elenco di nomi alternativi validi anche per l'oggetto (oltre al singolo nome comune / CN). I nomi di questo campo e jolly sono essenzialmente i due modi di utilizzare un certificato per più nomi.
SNI (Server Name Indication) è un'estensione del protocollo TLS che è una specie di protocollo TLS equivalente dell'intestazione host HTTP. Quando un client invia questo, consente al server di scegliere il certificato appropriato da presentare al client senza avere la limitazione di utilizzare indirizzi IP separati sul lato server (proprio come il modo in cui l'intestazione dell'host HTTP è ampiamente utilizzata per il semplice HTTP).
Si noti che SNI non è qualcosa che si riflette nel certificato e in realtà raggiunge il contrario di ciò che la domanda chiede; semplifica avere molti certificati, non usare un certificato per molte cose.
D'altra parte, dipende fortemente dalla situazione quale percorso è effettivamente preferibile. Ad esempio, ciò che la domanda pone non è quasi certo ciò che si desidera effettivamente se sono necessari certificati per entità diverse.
SAN è l' acronimo di Subject Alternative Name , ed è una proprietà del certificato x509 e SNI è una funzionalità che può supportare il client SSL / TLS, quindi un'entità totalmente diversa.
Utilizzando un certificato con SAN è possibile ospitare più siti abilitati HTTPS su un indirizzo IP anche se il client non supporta SNI . In questo caso possiedi un certificato per tutti i tuoi siti e tale certificato deve contenere tutti i nomi dei siti ( ServerNames o ServerAliasnelle coordinate apache o server_namein nginx) in quanto SAN . Questo è un sottoinsieme di un approccio legacy, quello che ha esteso "un sito abilitato HTTPS su ciascun indirizzo IP separato". Attualmente solo i CDN di grandi dimensioni si attaccano alla SAN .
Utilizzando SNI puoi anche ospitare più siti abilitati HTTPS su un solo IP, possiedi un certificato x509 separato per ciascun sito e nessuno di questi menziona altri nomi di siti nella loro proprietà SAN , ma client TLS (ovvero browser e client console come wgeto curl) deve supportare SNI . Questo è un approccio moderno, poiché l'ultimo sistema operativo che non supportava SNI immediatamente era Windows XP con IE 6.x, se ricordo bene. Al giorno d'oggi è possibile visualizzare la proprietà SAN se si acquista il certificato con caratteri jolly , ad esempio un tale certificato *.foobar.comconterrà un nome comune di *.foobar.come una SAN di foobar.com.
Questo mescola due parti del processo di certificazione.
Una SAN è un nome alternativo soggetto. È un modo per creare un certificato per più domini. È sufficiente aggiungere gli altri domini per i quali si desidera un certificato al campo SAN nel certificato. Il browser accetterà quindi la validità anche su questi domini.
SNI è l'indicazione del nome del server e fa parte di SSL. Ti consente di ospitare più siti SSL su un singolo IP perché il nome del server desiderato viene inviato con l'handshake SSL e il server può scegliere il certificato corretto per la risposta.
Ecco una risposta (forse) più leggibile dall'uomo:
SNI è condotto sul lato client e dice allo stack TLS "Voglio parlare con un server il cui nome è [Server X]". Il server vede questa stringa [Server X] e risponde con un certificato appropriato. Un esempio pratico è quando un singolo server deve servire il traffico per più domini. È inoltre utile se il client ha utilizzato un IP (per evitare ritardi nella ricerca DNS) ma il certificato CN non menziona l'IP.
SAN è un elenco di "Conosciuto anche come" nei certificati. In questo modo il server può utilizzare un singolo certificato per molti nomi. Si possono aggiungere molti domini allo stesso certificato e persino un elenco di IP.
Come puoi vedere, le cose si sovrappongono. Scegliere tra uno o entrambi dipende da dove si ha il controllo. Alcuni client potrebbero non riconoscere i nomi in SAN e l'unico modo per indirizzarli è fornire un certificato appropriato basato su SNI. Esistono scenari in cui il server fornisce l'API per un singolo certificato o il client non invia SNI. In questi casi, SAN è l'unica via d'uscita.
La mia azienda si avvale di entrambi. Offrono flessibilità e semplificano la compatibilità con le versioni precedenti e successive.