ブラウザがhttps://1.1.1.1が安全であると考えるのはなぜですか？

私が訪れたときhttps://1.1.1.1を、私が使用して、任意のWebブラウザでは、URLが安全であると考えています。

これは、Google Chromeが示すものです。

通常、IPアドレスを使用してHTTPSサイトにアクセスしようとすると、次のようなセキュリティ警告が表示されます。

私の理解では、サイト証明書はドメインと一致する必要がありますが、Google Chrome証明書ビューアには表示されません1.1.1.1：

GoDaddyのナレッジベース記事「イントラネット名またはIPアドレスの証明書を要求できますか？」言う：

いいえ-イントラネット名またはIPアドレスの証明書要求を受け付けなくなりました。これは業界全体の標準であり、GoDaddyに固有のものではありません。

^{_{（強調鉱山）}}

そしてまた：

その結果、2016年10月1日から、証明機関（CA）は、イントラネット名またはIPアドレスを使用するSSL証明書を失効させる必要があります。

^{_{（強調鉱山）}}

そして：

IPアドレスとイントラネット名を保護する代わりに、www.coolexample.comなどの完全修飾ドメイン名（FQDN）を使用するようにサーバーを再構成する必要があります。

^{_{（強調鉱山）}}

強制失効日が2016年10月1日を過ぎた後でも、1.1.1.12018年3月29日に証明書が発行されました（上のスクリーンショットを参照）。

すべての主要なブラウザがhttps://1.1.1.1が信頼できるHTTPS Webサイトであると考える可能性はありますか？

英語はあいまいです。次のように解析していました。

(intranet names) or (IP addresses)

すなわち、数値IPアドレスの使用を完全に禁止します。見ているものと一致する意味は次のとおりです。

intranet (names or IP addresses)

つまり、10.0.0.0 / 8、172.16.0.0 / 12、192.168.0.0 / 16などのプライベートIP範囲の証明書、およびパブリックDNSに表示されないプライベート名の証明書を禁止します。

パブリックにルーティング可能なIPアドレスの証明書は引き続き許可されますが、ほとんどの人、特に静的IPも所有していない人には一般的にお勧めしません。

この声明はアドバイスであり、（パブリック）IPアドレスを保護できないという主張ではありません。

IPアドレスとイントラネット名を保護する代わりに、www.coolexample.comなどの完全修飾ドメイン名（FQDN）を使用するようにサーバーを再構成する必要があります

GoDaddyの誰かが言い回しを誤って解釈していたかもしれませんが、おそらくアドバイスをシンプルに保ち、証明書にパブリックDNS名を使用することを推奨したかったのでしょう。

ほとんどの人は、サービスに安定した静的IPを使用しません。DNSサービスを提供することは、名前だけでなく安定した既知のIPを持つことが本当に必要な1つのケースです。 他の人にとって、現在のIPをSSL証明書に入れると、他の人にそのIPの使用を開始させることができなくなるため、将来のオプションが制約されます。彼らはあなたのサイトになりすますことができます。

Cloudflare.com は、1.1.1.1 IPアドレス自体を制御しており、近い将来、これとは異なることをする予定はないため、証明書にIPを入れることは理にかなっています。特にDNSプロバイダーとして、 HTTPSクライアントは他のサイトよりも番号でURLにアクセスする可能性が高くなります。

GoDaddyのドキュメントは間違っています。証明機関（CA）が...すべてのIPアドレスのための証明書を失効しなければならないというのは本当ではないだけで予約されたIPアドレスを。

^{_{ソース：https : //cabforum.org/internal-names/}}

https://1.1.1.1のCA はDigiCertでしたが、この回答の執筆時点では、パブリックIPアドレスのサイト証明書を購入できます。

DigiCertには、このことに関する2015年以降の内部サーバー名SSL証明書発行に関する記事があります。

内部名を使用するサーバー管理者の場合、パブリック名を使用するようにそれらのサーバーを再構成するか、2015年の締切日より前に内部CAによって発行された証明書に切り替える必要があります。公的に信頼された証明書を必要とするすべての内部接続は、公開され検証可能な名前を介して行われる必要があります（これらのサービスが公的にアクセス可能かどうかは関係ありません）。

^{_{（強調鉱山）}}

Cloudflareは、1.1.1.1その信頼できるCAからIPアドレスの証明書を取得しただけです。

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アドレスに有効です。

証明書サブジェクトの代替名に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/もブラウザによって安全であると見なされます。