Pourquoi mon navigateur pense-t-il que https://1.1.1.1 est sécurisé?
Lorsque je visite https://1.1.1.1 , tout navigateur Web que j'utilise considère que l'URL est sécurisée.
Voici ce que Google Chrome montre:
Normalement, lorsque j'essaie de visiter un site HTTPS via son adresse IP, je reçois un avertissement de sécurité comme celui-ci:
À ma connaissance, le certificat de site doit correspondre au domaine, mais la Visionneuse de certificat de Google Chrome n’affiche pas 1.1.1.1:
Non, nous n'acceptons plus les demandes de certificat pour les noms intranet ou les adresses IP. Il s'agit d'un standard de l'industrie , pas spécifique à GoDaddy.
( emphase mine)
Et aussi:
Par conséquent, à compter du 1er octobre 2016 , les autorités de certification (AC) doivent révoquer les certificats SSL qui utilisent noms intranet ou adresses IP .
( emphase mine)
Et:
Au lieu de sécuriser les adresses IP et les noms intranet, vous devez reconfigurer les serveurs pour qu'ils utilisent des noms de domaine complets (FQDN), tels que www.coolexample.com.
( emphase mine)
Bien après la date de révocation obligatoire du 1er octobre 2016, le certificat pour 1.1.1.1 a été délivré le 29 mars 2018 (voir la capture d'écran ci-dessus).
Comment est-il possible que tous les principaux navigateurs pensent que https://1.1.1.1 est un site Web HTTPS de confiance?
L'anglais est ambigu . Vous l'avez analysé comme ceci:
(intranet names) or (IP addresses)
c'est-à-dire interdire complètement l'utilisation d'adresses IP numériques. La signification qui correspond à ce que vous voyez est la suivante:
intranet (names or IP addresses)
c'est-à-dire interdire les certificats pour les plages d'adresses IP privées comme 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16, ainsi que pour les noms privés qui ne sont pas visibles sur le DNS public.
Les certificats pour les adresses IP routables publiquement sont toujours autorisés, n'est généralement pas recommandé pour la plupart des utilisateurs, en particulier ceux qui ne possèdent pas également une adresse IP statique.
Cette déclaration est un conseil et non une affirmation que vous ne pouvez passécuriser une adresse IP (publique).
Au lieu de sécuriser les adresses IP et les noms intranet, vous devez reconfigurer les serveurs pour qu'ils utilisent des noms de domaine complets (FQDN), tels que www.coolexample.com.
Quelqu'un chez GoDaddy a peut-être mal interprété le libellé, mais il était plus probable qu'il souhaitait garder ses conseils simples et qu'il recommandât d'utiliser des noms DNS publics dans les certificats.
La plupart des gens n'utilisent pas une adresse IP statique stable pour leur service. La fourniture de services DNS est le seul cas où il est vraiment nécessaire d’avoir une adresse IP bien connue stable au lieu d’un simple nom. Pour quiconque, placer votre adresse IP actuelle dans votre certificat SSL limiterait vos options futures, car vous ne pouviez pas laisser quelqu'un d'autre commencer à utiliser cette adresse IP. Ils pourraient imiter votre site.
Cloudflare.com a le contrôle de l’adresse IP 1.1.1.1 elle-même, et n’envisage pas de faire autre chose avec elle dans un avenir prévisible, il est donc logique que pour eux, mettre leur adresse IP Surtout en tant que fournisseur DNS, il est plus probable que les clients HTTPS consultent leur URL par numéro plutôt que sur tout autre site.
La documentation de GoDaddy est erronée. Il n’est pas vrai que les autorités de certification (AC) doivent révoquer les certificats de toutes les adresses IP… adresses IP réservées uniquement .
Source: https://cabforum.org/nternal-names/
L'AC pour https://1.1.1.1 était DigiCert , qui, à la date de rédaction de cette réponse, permet l'achat de certificats de site pour des adresses IP publiques.
DigiCert a publié un article à ce sujet intitulé Nom du serveur interne, émission de certificats SSL après 2015 :
Si vous êtes un administrateur de serveur utilisant des noms internes, vous devez reconfigurer ces serveurs pour utiliser un nom public ou passer à un certificat émis par une autorité de certification interne avant la date limite de 2015. Toutes les connexions internes nécessitant un certificat de confiance publique doivent être effectuées à l'aide de noms public et vérifiable (peu importe si ces services sont accessibles au public).
( emphase mine)
Cloudflare a simplement obtenu un certificat pour son adresse IP 1.1.1.1 de cette autorité de certification approuvée.
L'analyse du certificat pour https://1.1.1.1 révèle que le certificat utilise des noms alternatifs de sujet (SAN) pour englober certaines adresses IP et noms de domaine ordinaires:
deltik@node51 [~]$ openssl s_client -showcerts -connect 1.1.1.1:443 < /dev/null 2>&1 | openssl x509 -noout -text | grep -A1 'Subject Alternative Name:'
X509v3 Subject Alternative Name:
DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001
Ces informations figurent également dans l'afficheur de certificats Google Chrome sous l'onglet "Détails":
Ce certificat est valide pour tous les domaines répertoriés (y compris le caractère générique *) et les adresses IP.
On dirait que le nom de remplacement du sujet du certificat comprend l'adresse IP:
Not Critical
DNS Name: *.cloudflare-dns.com
IP Address: 1.1.1.1
IP Address: 1.0.0.1
DNS Name: cloudflare-dns.com
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001
Traditionnellement, je suppose que vous n’auriez mis que des noms DNS ici, mais Cloudflare a également indiqué ses adresses IP.
https://1.0.0.1/ est également considéré comme sécurisé par les navigateurs.