Why does my browser think that https://1.1.1.1 is secure?

Question

When I visit https://1.1.1.1, any web browser I use considers the URL to be secure.

This is what Google Chrome shows:

Normally, when I try to visit an HTTPS site via its IP address, I get a security warning like this:

From my understanding, the site certificate needs to match the domain, but the Google Chrome Certificate Viewer does not show 1.1.1.1:

GoDaddy's knowledgebase article "Can I request a certificate for an intranet name or IP address?" says:

No - we no longer accept certificate requests for either intranet names or IP addresses. This is an industry-wide standard, not one specific to GoDaddy.

^{_{(emphasis mine)}}

And also:

As a result, effective October 1, 2016, Certification Authorities (CAs) must revoke SSL certificates that use intranet names or IP addresses.

^{_{(emphasis mine)}}

And:

Instead of securing IP addresses and intranet names, you should reconfigure servers to use Fully Qualified Domain Names (FQDNs), such as www.coolexample.com.

^{_{(emphasis mine)}}

It's well after the mandatory revocation date 01 October 2016, yet the certificate for 1.1.1.1 was issued on 29 March 2018 (shown in the screenshot above).

---

How is it possible that all the major browsers think that https://1.1.1.1 is a trusted HTTPS website?

Answer 1

The GoDaddy documentation is mistaken. It is not true that Certification Authorities (CAs) must revoke certificates for all IP addresses… just reserved IP addresses.

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

The CA for https://1.1.1.1 was DigiCert, which as of the writing of this answer, does allow buying site certificates for public IP addresses.

DigiCert has an article about this called Internal Server Name SSL Certificate Issuance After 2015:

If you are a server admin using internal names, you need to either reconfigure those servers to use a public name, or switch to a certificate issued by an internal CA before the 2015 cutoff date. All internal connections that require a publicly-trusted certificate must be done through names that are public and verifiable (it does not matter if those services are publicly accessible).

^{_{(emphasis mine)}}

Cloudflare simply got a certificate for their IP address 1.1.1.1 from that trusted CA.

Parsing the certificate for https://1.1.1.1 reveals that the certificate makes use of Subject Alternative Names (SANs) to encompass some IP addresses and ordinary domain names:

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

This information is also in the Google Chrome Certificate Viewer under the "Details" tab:

This certificate is valid for all of the listed domains (including the wildcard *) and IP addresses.

Answer 2

English is ambiguous. You were parsing it like this:

(intranet names) or (IP addresses)

i.e. ban the use of numeric IP addresses entirely. The meaning that matches what you're seeing is:

intranet (names or IP addresses)

i.e. ban certificates for the private IP ranges like 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as well as for private names that aren't visible on the public DNS.

Certificates for publicly routable IP addresses are still allowed, just not generally recommended for most people, especially those who don't also own a static IP.

---

This statement is advice, not a claim that you can't secure a (public) IP address.

Instead of securing IP addresses and intranet names, you should reconfigure servers to use Fully Qualified Domain Names (FQDNs), such as www.coolexample.com

Maybe someone at GoDaddy was misinterpreting the wording, but more likely they wanted to keep their advice simple, and wanted to recommend using public DNS names in certificates.

Most people don't use a stable static IP for their service. Providing DNS services is the one case where it's truly necessary to have a stable well-known IP instead of just a name. For anyone else, putting your current IP in your SSL cert would constrain your future options, because you couldn't let someone else start using that IP. They could impersonate your site.

Cloudflare.com has control of the 1.1.1.1 IP address themselves, and isn't planning to do anything different with it in the foreseeable future, so it makes sense for them to put their IP in their cert. Especially as a DNS provider, it's more likely that HTTPS clients would visit their URL by number than for any other site.

Answer 3

Looks like the Certificate Subject Alt Name includes the IP address:

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

Traditionally I guess you would have only put DNS Names in here, but Cloudflare have put their IP Addresses in as well.

https://1.0.0.1/ is also considered secure by browsers.