OpenSSL renvoie un certificat SSL différent de celui affiché par Chrome

Lors de l'interrogation de l'URL CDN de Sparkfun à l'aide d'OpenSSL avec la commande suivante:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

Le nom commun renvoyé dans le certificat est *.sparkfun.com, ce qui échoue à vérifier, mais si vous chargez l'hôte dans Chrome, le nom commun affiché est*.cloudfront.net

Qu'est-ce qui se passe ici?

Cela cause un problème car l'environnement dans lequel je suis dans les proxys SSL via Squid SSL_Bump, qui génère un certificat signé par mon autorité de certification localement approuvée pour le domaine. Cela fonctionne pour tous les domaines mais ci-dessus, car le CN ne correspond pas car le nouveau certificat est généré à l'aide d'OpenSSL.

ÉDITER - J'ai vérifié que la même chose se produit avec OpenSSL sur un serveur dans un centre de données distant qui a une connexion directe à Internet sans proxy ni filtrage.

EDIT - Le problème est dû à SNI, tel qu'accepté, mais pour remplir les informations expliquant pourquoi il provoque un problème avec Squid et SSL_Bump:

Ce projet ne prendra pas en charge le transfert des informations SNI (SSL Server Name Indication) au serveur d'origine et rendra cette prise en charge un peu plus difficile. Cependant, le transfert SNI a ses propres défis sérieux (au-delà de la portée de ce document) qui dépassent de loin les difficultés supplémentaires de transfert.

Tiré de: http://wiki.squid-cache.org/Features/BumpSslServerFirst

CloudFront utilise SNI, un moyen de pouvoir utiliser plusieurs certificats sur une seule IP. Tous les navigateurs modernes prennent en charge cela, tout comme la commande s_client de openssl, mais s_client ne le fait pas comme par magie. Vous devez lui dire de l'utiliser:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

Chrome prend en charge SNI , indiquant au serveur quel certificat envoyer. La s_clientcommande ne fonctionne pas.

Il y a plus de détails sur l'utilisation de SNI par CloudFront ici .

Lorsque vous utilisez SSL personnalisé SNI, certains utilisateurs peuvent ne pas être en mesure d'accéder à votre contenu car certains navigateurs plus anciens ne prennent pas en charge SNI et ne pourront pas établir de connexion avec CloudFront pour charger la version HTTPS de votre contenu. Pour plus d'informations sur SNI, y compris une liste des navigateurs pris en charge, veuillez visiter notre page FAQ .

et:

SNI SSL personnalisé repose sur l'extension SNI du protocole Transport Layer Security, qui permet à plusieurs domaines de servir le trafic SSL sur la même adresse IP en incluant les visionneuses de nom d'hôte qui tentent de se connecter. Comme pour SSL personnalisé IP dédié, CloudFront fournit du contenu à partir de chaque emplacement périphérique Amazon CloudFront et avec la même sécurité que la fonctionnalité SSL personnalisé IP dédié. SNI Custom SSL fonctionne avec la plupart des navigateurs modernes, y compris Chrome version 6 et versions ultérieures (fonctionnant sous Windows XP et versions ultérieures ou OS X 10.5.7 et versions ultérieures), Safari version 3 et versions ultérieures (fonctionnant sous Windows Vista et versions ultérieures ou Mac OS X 10.5. 6. et versions ultérieures), Firefox 2.0 et versions ultérieures et Internet Explorer 7 et versions ultérieures (fonctionnant sous Windows Vista et versions ultérieures). Les navigateurs plus anciens qui ne prennent pas en charge SNI ne peuvent pas établir de connexion avec CloudFront pour charger la version HTTPS de votre contenu.