Por que meu navegador acha que https://1.1.1.1 é seguro?

Quando visito https://1.1.1.1 , qualquer navegador da Web que eu considere considera o URL seguro.

Isto é o que o Google Chrome mostra:

Normalmente, quando tento visitar um site HTTPS por meio do endereço IP, recebo um aviso de segurança como este:

Pelo meu entendimento, o certificado do site precisa corresponder ao domínio, mas o Visualizador de Certificados do Google Chrome não mostra 1.1.1.1:

Artigo da GoDaddy na base de conhecimento "Posso solicitar um certificado para um nome de intranet ou endereço IP?" diz:

Não - não aceitamos mais solicitações de certificado para nomes de intranet ou endereços IP. Esse é um padrão de todo o setor , não específico do GoDaddy.

^{_{( ênfase minha)}}

E também:

Como resultado, a partir de 1º de outubro de 2016 , as Autoridades de Certificação (CAs) devem revogar certificados SSL que usam nomes de intranet ou endereços IP .

^{_{( ênfase minha)}}

E:

Em vez de proteger endereços IP e nomes da intranet, você deve reconfigurar os servidores para usar os FQDNs (nomes de domínio totalmente qualificados), como www.coolexample.com .

^{_{( ênfase minha)}}

É bem após a data de revogação obrigatória em 01 de outubro de 2016, mas o certificado 1.1.1.1foi emitido em 29 de março de 2018 (mostrado na captura de tela acima).

Como é possível que todos os principais navegadores pensem que https://1.1.1.1 é um site HTTPS confiável?

Inglês é ambíguo . Você estava analisando assim:

(intranet names) or (IP addresses)

ou seja, proibir totalmente o uso de endereços IP numéricos. O significado que corresponde ao que você está vendo é:

intranet (names or IP addresses)

ou seja, proibir certificados para os intervalos de IP privados como 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, bem como para nomes particulares que não são visíveis no DNS público.

Certificados para endereços IP roteados publicamente ainda são permitidos, mas geralmente não são recomendados para a maioria das pessoas, especialmente aquelas que também não possuem um IP estático.

Esta declaração é um conselho, não uma alegação de que você não pode proteger um endereço IP (público).

Em vez de proteger endereços IP e nomes da intranet, você deve reconfigurar os servidores para usar os FQDNs (nomes de domínio totalmente qualificados), como www.coolexample.com

Talvez alguém do GoDaddy tenha interpretado mal o texto, mas é mais provável que eles desejem manter seus conselhos simples e que recomendem o uso de nomes DNS públicos em certificados.

A maioria das pessoas não usa um IP estático estável para seus serviços. O fornecimento de serviços DNS é o único caso em que é realmente necessário ter um IP conhecido e estável em vez de apenas um nome. Para qualquer outra pessoa, colocar o seu IP atual no seu certificado SSL restringiria suas opções futuras, porque você não poderia permitir que outra pessoa começasse a usá-lo. Eles podem se passar por seu site.

O Cloudflare.com possui o controle do endereço IP 1.1.1.1 e não planeja fazer algo diferente com ele em um futuro próximo, por isso faz sentido que eles coloquem o IP no certificado. Especialmente como provedor de DNS , é mais provável que os clientes HTTPS visitem seu URL por número do que em qualquer outro site.

A documentação do GoDaddy está errada. Não é verdade que as autoridades de certificação (CAs) devem revogar certificados para todos os endereços IP ... apenas endereços IP reservados .

^{_{Fonte: https://cabforum.org/internal-names/}}

A autoridade de certificação para https://1.1.1.1 era o DigiCert , que, ao escrever esta resposta, permite comprar certificados de site para endereços IP públicos.

O DigiCert tem um artigo sobre isso chamado Emissão interna de certificado SSL de nome de servidor após 2015 :

Se você for um administrador de servidor usando nomes internos, precisará reconfigurar esses servidores para usar um nome público ou alternar para um certificado emitido por uma CA interna antes da data limite de 2015. Todas as conexões internas que exigem um certificado de confiança pública devem ser feitas por nomes públicos e verificáveis (não importa se esses serviços são acessíveis ao público).

^{_{( ênfase minha)}}

O Cloudflare simplesmente obteve um certificado para o endereço IP 1.1.1.1dessa CA confiável.

A análise do certificado para https://1.1.1.1 revela que o certificado utiliza SANs (Subject Alternative Names) para abranger alguns endereços IP e nomes de domínio comuns:

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

Essas informações também estão no Visualizador de certificados do Google Chrome, na guia "Detalhes":

Este certificado é válido para todos os domínios listados (incluindo o curinga *) e endereços IP.

Parece que o Nome Alt do Assunto do Certificado inclui o endereço 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

Tradicionalmente, acho que você só colocaria nomes DNS aqui, mas o Cloudflare também colocou seus endereços IP.

https://1.0.0.1/ também é considerado seguro pelos navegadores.