Dlaczego moja przeglądarka uważa, że ​​https://1.1.1.1 jest bezpieczny?

Kiedy odwiedzam https://1.1.1.1 , każda przeglądarka internetowa, której używam, uważa adres URL za bezpieczny.

Oto, co pokazuje Google Chrome:

Zwykle, gdy próbuję odwiedzić witrynę HTTPS za pośrednictwem jej adresu IP, otrzymuję takie ostrzeżenie bezpieczeństwa:

Z mojego zrozumienia, certyfikat witryny musi pasować do domeny, ale przeglądarka certyfikatów Google Chrome nie wyświetla 1.1.1.1:

Artykuł bazy wiedzy GoDaddy „Czy mogę poprosić o certyfikat dla nazwy intranetowej lub adresu IP?” mówi:

Nie - nie przyjmujemy już wniosków o certyfikaty dla nazw intranetowych ani adresów IP. Jest to standard branżowy , a nie specyficzny dla GoDaddy.

^{_{( moje podkreślenie )}}

I również:

W związku z tym od 1 października 2016 r. Urzędy certyfikacji muszą unieważnić certyfikaty SSL korzystające z nazw intranetowych lub adresów IP .

^{_{( moje podkreślenie )}}

I:

Zamiast zabezpieczać adresy IP i nazwy intranetowe, należy ponownie skonfigurować serwery, aby używały w pełni kwalifikowanych nazw domen (FQDN), takich jak www.coolexample.com .

^{_{( moje podkreślenie )}}

Minęło dużo czasu od daty obowiązkowego unieważnienia 01 października 2016 r., Ale certyfikat 1.1.1.1wydano 29 marca 2018 r. (Pokazany na zrzucie ekranu powyżej).

Jak to możliwe, że wszystkie główne przeglądarki uważają, że https://1.1.1.1 jest zaufaną witryną HTTPS?

Angielski jest dwuznaczny . Przetwarzałeś to w ten sposób:

(intranet names) or (IP addresses)

tzn. całkowicie zakazać używania numerycznych adresów IP. Znaczenie, które pasuje do tego, co widzisz, to:

intranet (names or IP addresses)

tzn. certyfikaty banów dla prywatnych zakresów adresów IP, takich jak 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16, a także dla prywatnych nazw, które nie są widoczne w publicznym DNS.

Certyfikaty dla publicznie rutowalnych adresów IP są nadal dozwolone, ale ogólnie nie są zalecane dla większości ludzi, szczególnie tych, którzy nie posiadają również statycznego adresu IP.

To oświadczenie jest poradą, a nie twierdzeniem, że nie możesz zabezpieczyć (publicznego) adresu IP.

Zamiast zabezpieczać adresy IP i nazwy intranetowe, należy ponownie skonfigurować serwery, aby używały w pełni kwalifikowanych nazw domen (FQDN), takich jak www.coolexample.com

Może ktoś w GoDaddy źle interpretuje to sformułowanie, ale bardziej prawdopodobne jest, że chciałby, aby ich porady były proste, i zalecił użycie publicznych nazw DNS w certyfikatach.

Większość ludzi nie używa stabilnego statycznego adresu IP do swoich usług. Świadczenie usług DNS to jedyny przypadek, w którym naprawdę konieczne jest posiadanie stabilnego, dobrze znanego adresu IP, a nie tylko nazwy. Dla każdego innego umieszczenie twojego aktualnego adresu IP w certyfikacie SSL ograniczyłoby twoje przyszłe opcje, ponieważ nie możesz pozwolić, aby ktoś inny zaczął korzystać z tego adresu IP. Mogą podszyć się pod Twoją witrynę.

Cloudflare.com ma kontrolę nad tym 1.1.1.1 Adres IP sami, i nie zamierza robić niczego innego się z nim w dającej się przewidzieć przyszłości, więc ma to sens dla nich umieścić swoje IP w ich cert. Zwłaszcza jako dostawca DNS bardziej prawdopodobne jest, że klienci HTTPS odwiedzą ich adres URL według numeru, niż w przypadku jakiejkolwiek innej witryny.

Dokumentacja GoDaddy jest błędna. To nieprawda, że ​​urzędy certyfikacji muszą odwoływać certyfikaty dla wszystkich adresów IP… tylko zarezerwowane adresy IP .

^{_{Źródło: https://cabforum.org/internal-names/}}

Urząd certyfikacji dla https://1.1.1.1 był DigiCert , który w chwili pisania tej odpowiedzi umożliwia kupowanie certyfikatów witryny dla publicznych adresów IP.

DigiCert ma artykuł na ten temat o nazwie Wydawanie certyfikatu SSL wewnętrznego serwera po 2015 roku :

Jeśli jesteś administratorem serwera używającym nazw wewnętrznych, musisz albo ponownie skonfigurować te serwery, aby używały nazwy publicznej, lub przełączyć się na certyfikat wydany przez wewnętrzny urząd certyfikacji przed datą graniczną w 2015 r. Wszystkie połączenia wewnętrzne wymagające publicznie zaufanego certyfikatu muszą być nawiązywane za pomocą nazw publicznych i weryfikowalnych (nie ma znaczenia, czy usługi te są publicznie dostępne).

^{_{( moje podkreślenie )}}

Cloudflare po prostu otrzymał certyfikat na swój adres IP 1.1.1.1od tego zaufanego urzędu certyfikacji.

Analiza parsowanego certyfikatu dla https://1.1.1.1 ujawnia, że ​​certyfikat wykorzystuje alternatywne nazwy podmiotu (SAN) w celu uwzględnienia niektórych adresów IP i zwykłych nazw domen:

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

Te informacje znajdują się również w przeglądarce certyfikatów Google Chrome na karcie „Szczegóły”:

Ten certyfikat jest ważny na wszystkie wymienione domeny (w tym symbol wieloznaczny *) i adresy IP.

Wygląda na to, że nazwa podmiotu certyfikatu zawiera adres 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

Tradycyjnie myślę, że umieściłbyś tutaj tylko Nazwy DNS, ale Cloudflare umieścił również ich Adresy IP.

Przeglądarki uważają również https://1.0.0.1/ za bezpieczne.