Quelqu'un pourrait-il m'expliquer la différence entre ces certificats de manière simplifiée? J'ai lu certains articles, mais il semble qu'ils font le même travail, à savoir le cryptage de nombreux domaines avec un seul certificat.
Réponses:
SAN (Subject Alternative Name) fait partie de la spécification de certificat X509 , où le certificat a un champ avec une liste de noms alternatifs qui sont également valides pour le sujet (en plus du seul nom commun / CN). Ce champ et les noms génériques sont essentiellement les deux façons d'utiliser un certificat pour plusieurs noms.
SNI (Server Name Indication) est une extension de protocole TLS qui est en quelque sorte un équivalent de protocole TLS de l'en-tête d'hôte HTTP. Lorsqu'un client envoie cela, il permet au serveur de choisir le certificat approprié à présenter au client sans avoir la limitation d'utiliser des adresses IP distinctes côté serveur (un peu comme la façon dont l'en-tête de l'hôte HTTP est largement utilisé pour le HTTP simple).
Notez que le SNI n'est pas quelque chose qui se reflète dans le certificat et il réalise en fait un peu le contraire de ce que la question demande; cela simplifie la possession de nombreux certificats, sans utiliser un seul certificat pour beaucoup de choses.
D'un autre côté, cela dépend fortement de la situation, quelle voie est réellement préférable. À titre d'exemple, ce que la question demande n'est certainement pas ce que vous voulez réellement si vous avez besoin de certificats pour différentes entités.
SAN signifie Subject Alternative Name , et c'est une propriété de certificat x509, et SNI est une fonctionnalité que le client SSL / TLS peut prendre en charge, donc une entité totalement différente.
À l'aide d'un certificat avec SAN, vous pouvez héberger plusieurs sites compatibles HTTPS sur une même adresse IP même si le client ne prend pas en charge SNI . Dans ce cas, vous détenez un certificat pour tous vos sites, et ce certificat doit contenir tous les noms de site ( ServerNames ou ServerAliases dans les coordonnées apache ou server_namedans nginx) car il s'agit de SAN . Il s'agit d'un sous-ensemble d'une approche héritée, celle qui a étendu "un site compatible HTTPS sur chaque adresse IP distincte". Actuellement, seuls les gros CDN restent avec SAN .
En utilisant SNI, vous pouvez également héberger plusieurs sites compatibles HTTPS sur une IP, vous détenez un certificat x509 distinct pour chaque site et aucun de ces deux ne mentionne d'autres noms de site dans leur propriété SAN , mais des clients TLS (c'est-à-dire des navigateurs et des clients de console tels que wgetou curl) doit prendre en charge SNI . Il s'agit d'une approche moderne, car le dernier système d'exploitation ne prenant pas en charge SNI prêt à l'emploi était Windows XP avec IE 6.x, si je me souviens bien. De nos jours, vous pouvez voir la propriété SAN si vous achetez le certificat générique - par exemple, un tel certificat pour *.foobar.comcontiendra un nom commun de *.foobar.comet un SAN de foobar.com.
Cela mélange deux parties du processus de certification.
Un SAN est un autre nom de sujet. C'est un moyen de créer un certificat pour plusieurs domaines. Vous ajoutez simplement les autres domaines pour lesquels vous souhaitez un certificat au champ SAN du certificat. Le navigateur acceptera également la validité de ces domaines.
SNI est l'indication du nom du serveur et fait partie de SSL. Il vous permet d'héberger plusieurs sites SSL sur une seule IP car le nom de serveur souhaité est envoyé avec la négociation SSL et le serveur peut choisir le certificat correct pour la réponse.
Voici une réponse (peut-être) plus lisible par l'homme:
SNI est effectué côté client et indique à la pile TLS "Je veux parler à un serveur dont le nom est [Serveur X]". Le serveur voit cette chaîne [Server X] et répond avec un certificat approprié. Un exemple pratique est lorsqu'un seul serveur doit servir le trafic pour plusieurs domaines. Il est également utile si le client a utilisé une adresse IP (pour éviter les retards de recherche DNS) mais que le certificat CN ne mentionne pas l'adresse IP.
SAN est une liste de "Aussi connu comme" dans les certificats. De cette façon, le serveur peut utiliser un seul certificat pour de nombreux noms. On peut ajouter plusieurs domaines au même certificat et même une liste d'adresses IP.
Comme vous pouvez le voir, les choses se chevauchent. Le choix entre l'un ou les deux dépend de l'endroit où l'on a le contrôle. Certains clients peuvent ne pas reconnaître les noms dans SAN et la seule façon de résoudre ce problème consiste à fournir un certificat approprié basé sur SNI. Il existe des scénarios où le serveur fournit une API pour un seul certificat ou si le client n'envoie pas SNI. Pour ces cas, le SAN est la seule issue.
Mon entreprise utilise les deux. Ils offrent une flexibilité et facilitent la compatibilité ascendante et descendante.