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:

Article de la base de connaissances de GoDaddy "Puis-je demander un certificat pour un nom intranet ou une adresse IP?" dit:

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 , et non spécifique à GoDaddy.

^{_{(c'est moi qui souligne )}}

Et aussi:

Par conséquent, à compter du 1er octobre 2016 , les autorités de certification (AC) doivent révoquer les certificats SSL qui utilisent des noms intranet ou des adresses IP .

^{_{(c'est moi qui souligne )}}

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 entièrement qualifiés (FQDN), tels que www.coolexample.com .

^{_{(c'est moi qui souligne )}}

C'est bien après la date de révocation obligatoire du 1er octobre 2016, mais le certificat a 1.1.1.1été émis pour 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 des adresses IP numériques. La signification qui correspond à ce que vous voyez est la suivante:

intranet (names or IP addresses)

C'est-à-dire des certificats d'interdiction pour les plages d'adresses IP privées telles que 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, mais ils ne sont généralement pas recommandés 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 pas sé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, inscrire votre adresse IP actuelle dans votre certificat SSL limiterait vos options futures, car vous ne pouviez pas laisser quelqu'un d'autre utiliser cette adresse IP. Ils pourraient se faire passer pour 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 cette adresse dans un avenir proche. Il est donc logique qu’ils inscrivent leur adresse IP dans leur cert. Surtout en tant que fournisseur DNS , il est plus probable que les clients HTTPS consultent leur URL par numéro que pour 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 pour toutes les adresses IP… uniquement les adresses IP réservées .

^{_{Source: https://cabforum.org/nternal-names/}}

DigiCert était l’ autorité de certification de https://1.1.1.1 qui, à la date de rédaction de cette réponse, autorise l’achat de certificats de site pour les adresses IP publiques.

DigiCert a publié un article à ce sujet intitulé Délivrance de certificats SSL après 2015 : Nom du serveur interne :

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 publics et vérifiables (peu importe si ces services sont accessibles au public).

^{_{(c'est moi qui souligne )}}

Cloudflare a simplement obtenu un certificat pour son adresse IP 1.1.1.1de 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 du sujet du certificat inclut 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.