¿Por qué mi navegador piensa que https://1.1.1.1 es seguro?

Cuando visito https://1.1.1.1 , cualquier navegador web que uso considera que la URL es segura.

Esto es lo que muestra Google Chrome:

Normalmente, cuando intento visitar un sitio HTTPS a través de su dirección IP, recibo una advertencia de seguridad como esta:

Según tengo entendido, el certificado del sitio debe coincidir con el dominio, pero el Visor de certificados de Google Chrome no muestra 1.1.1.1:

Artículo de la base de conocimiento de GoDaddy "¿Puedo solicitar un certificado para un nombre de intranet o dirección IP?" dice:

No, ya no aceptamos solicitudes de certificados para nombres de intranet o direcciones IP. Este es un estándar de toda la industria , no uno específico para GoDaddy.

^{_{( énfasis mío)}}

Y también:

Como resultado, a partir del 1 de octubre de 2016 , las Autoridades de Certificación (CA) deben revocar los certificados SSL que usan nombres de intranet o direcciones IP .

^{_{( énfasis mío)}}

Y:

En lugar de proteger las direcciones IP y los nombres de la intranet, debe reconfigurar los servidores para usar nombres de dominio completos (FQDN), como www.coolexample.com .

^{_{( énfasis mío)}}

Es mucho después de la fecha de revocación obligatoria del 1 de octubre de 2016, pero el certificado 1.1.1.1se emitió el 29 de marzo de 2018 (como se muestra en la captura de pantalla anterior).

¿Cómo es posible que todos los principales navegadores piensen que https://1.1.1.1 es un sitio web confiable de HTTPS?

El inglés es ambiguo . Lo estabas analizando así:

(intranet names) or (IP addresses)

es decir, prohibir el uso de direcciones IP numéricas por completo. El significado que coincide con lo que estás viendo es:

intranet (names or IP addresses)

es decir, prohibir los certificados para los rangos de IP privados como 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16, así como para los nombres privados que no son visibles en el DNS público.

Los certificados para direcciones IP enrutables públicamente todavía están permitidos, pero generalmente no se recomiendan para la mayoría de las personas, especialmente para aquellos que tampoco poseen una IP estática.

Esta declaración es un consejo, no una afirmación de que no puede asegurar una dirección IP (pública).

En lugar de proteger las direcciones IP y los nombres de la intranet, debe volver a configurar los servidores para usar nombres de dominio completos (FQDN), como www.coolexample.com

Tal vez alguien en GoDaddy estaba malinterpretando la redacción, pero lo más probable es que quisieran mantener sus consejos simples y recomendar el uso de nombres DNS públicos en los certificados.

La mayoría de las personas no usan una IP estática estable para su servicio. Proporcionar servicios de DNS es el único caso en el que es realmente necesario tener una IP estable y conocida en lugar de solo un nombre. Para cualquier otra persona, poner su IP actual en su certificado SSL restringiría sus opciones futuras, porque no podría permitir que otra persona comience a usar esa IP. Podrían hacerse pasar por su sitio.

Cloudflare.com tiene el control de la IP 1.1.1.1 abordar sí mismos, y no está planeando hacer algo diferente con ella en un futuro previsible, por lo que tiene sentido para ellos pongan su IP en su cert. Especialmente como proveedor de DNS , es más probable que los clientes HTTPS visiten su URL por número que cualquier otro sitio.

La documentación de GoDaddy está equivocada. No es cierto que las Autoridades de Certificación (CA) deben revocar los certificados para todas las direcciones IP ... solo direcciones IP reservadas .

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

La CA para https://1.1.1.1 fue DigiCert , que al momento de escribir esta respuesta, permite comprar certificados de sitio para direcciones IP públicas.

DigiCert tiene un artículo sobre esto llamado Emisión de certificado SSL de nombre de servidor interno después de 2015 :

Si usted es un administrador del servidor que usa nombres internos, debe reconfigurar esos servidores para usar un nombre público o cambiar a un certificado emitido por una CA interna antes de la fecha límite de 2015. Todas las conexiones internas que requieren un certificado de confianza pública deben realizarse a través de nombres que sean públicos y verificables (no importa si esos servicios son de acceso público).

^{_{( énfasis mío)}}

Cloudflare simplemente obtuvo un certificado para su dirección IP 1.1.1.1de esa CA confiable.

Analizar el certificado para https://1.1.1.1 revela que el certificado utiliza Nombres alternativos de sujeto (SAN) para abarcar algunas direcciones IP y nombres de dominio ordinarios:

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

Esta información también se encuentra en el Visor de certificados de Google Chrome en la pestaña "Detalles":

Este certificado es válido para todos los dominios enumerados (incluido el comodín *) y las direcciones IP.

Parece que el nombre alternativo del sujeto del certificado incluye la dirección 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, supongo que solo habría puesto nombres DNS aquí, pero Cloudflare también ha puesto sus direcciones IP.

https://1.0.0.1/ también es considerado seguro por los navegadores.