Чому мій браузер вважає, що https://1.1.1.1 захищено?

Коли я відвідую https://1.1.1.1 , будь-який веб-браузер, який я використовую, вважає URL-адресою захищеною.

Ось що показує Google Chrome:

Зазвичай, коли я намагаюся завітати на сайт HTTPS через його IP-адресу, я отримую попередження про безпеку таким чином:

Наскільки я розумію, сертифікат сайту повинен відповідати домену, але переглядач сертифікатів Google Chrome не показує 1.1.1.1:

Стаття бази даних GoDaddy "Чи можу я вимагати сертифікат на ім'я інтрамережі або IP-адресу?" каже:

Ні - ми більше не приймаємо запити на сертифікати ні для імен внутрішньої мережі, ні для IP-адрес. Це загальновиробничий стандарт , не один специфічний для GoDaddy.

^{_{( наголос мій)}}

І також:

Як результат, з 1 жовтня 2016 року органи з сертифікації (CA) повинні відкликати сертифікати SSL, які використовують імена інтрамережі або IP-адреси .

^{_{( наголос мій)}}

І:

Замість того, щоб захищати IP-адреси та імена інтрамережі, слід переконфігурувати сервери для використання повністю кваліфікованих доменних імен (FQDN), таких як www.coolexample.com .

^{_{( наголос мій)}}

Це вже після дати обов'язкової ануляції 01 жовтня 2016 року, але сертифікат на 1.1.1.1виданий був 29 березня 2018 року (показано на знімку екрана вище).

Як можливо, що всі основні браузери думають, що https://1.1.1.1 - це надійний веб-сайт HTTPS?

Англійська мова неоднозначна . Ви розбирали його так:

(intranet names) or (IP addresses)

тобто заборонити використання числових IP-адрес повністю. Сенс, який відповідає тому, що ви бачите:

intranet (names or IP addresses)

тобто сертифікати заборони для приватних IP-діапазонів, таких як 10.0.0.0/8, 172.16.0.0/12 та 192.168.0.0/16, а також для приватних імен, які не відображаються у загальнодоступній DNS.

Сертифікати на загальнодоступні маршрутизовані IP-адреси все ще дозволені, просто загалом не рекомендуються для більшості людей, особливо тих, хто також не має статичного IP-адреси.

Ця заява є порадою, а не твердженням, що ви не можете захистити (загальнодоступну) IP-адресу.

Замість того, щоб захищати IP-адреси та імена інтрамережі, слід переналаштувати сервери для використання повністю кваліфікованих доменних імен (FQDN), таких як www.coolexample.com

Можливо, хтось із GoDaddy неправильно трактував формулювання, але, швидше за все, вони хотіли зробити їх поради простими, і хотіли порекомендувати використовувати загальнодоступні імена DNS у сертифікатах.

Більшість людей не використовують стабільний статичний IP для своєї служби. Надання DNS-послуг - єдиний випадок, коли справді необхідно мати стабільний добре відомий IP-адресу замість простого імені. Для будь-кого іншого, розміщення вашого поточного IP-коду у вашій SSL-серці обмежуватиме ваші майбутні варіанти, оскільки ви не можете дозволити комусь іншому почати використовувати цей IP. Вони можуть представити себе за ваш сайт.

Cloudflare.com має власний контроль над IP-адресою 1.1.1.1, і не планує робити з нею нічого іншого в осяжному майбутньому, тому для них є сенс вводити IP-адресу в їхню версію. Тим більше, що як постачальник DNS , швидше за все, клієнти HTTPS відвідуватимуть їх URL за номером, ніж будь-який інший сайт.

Документація GoDaddy помилкова. Це неправда, що органи сертифікації (CA) повинні відкликати сертифікати на всі IP-адреси ... просто зарезервовані IP-адреси .

^{_{Джерело: https://cabforum.org/internal-names/}}

CA для https://1.1.1.1 був DigiCert , який на момент написання цієї відповіді дозволяє купувати сертифікати сайту для публічних IP-адрес.

DigiCert має статтю про це під назвою Випуск SSL сертифіката внутрішнього імені після 2015 року :

Якщо ви адміністратор сервера, що використовує внутрішні імена, вам потрібно або перенастроїти ці сервери на загальнодоступне ім’я, або перейти на сертифікат, виданий внутрішнім органом влади до дати відключення 2015 року. Усі внутрішні з'єднання, для яких потрібен сертифікат, що має довіреність, повинні здійснюватися через імена, які є загальнодоступними та перевіряються (не має значення, чи є ці служби загальнодоступними).

^{_{( наголос мій)}}

Cloudflare просто отримав сертифікат на свою IP-адресу 1.1.1.1від цього довіреного ЦА.

Аналіз сертифіката для https://1.1.1.1 виявляє, що сертифікат використовує суб'єктивні альтернативні імена (SAN), щоб охопити деякі IP-адреси та звичайні доменні імена:

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

Ця інформація також знаходиться у переглядачі сертифікатів Google Chrome на вкладці "Деталі":

Цей сертифікат дійсний для всіх перелічених доменів (включаючи підстановку *) та IP-адреси.

Схоже, ім'я Alt предмета сертифіката включає 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

Традиційно я думаю, ви б сюди ввели лише DNS-імена, але Cloudflare також розмістив свої IP адреси.

https://1.0.0.1/ також вважається захищеним браузерами.