128

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:

Google Chrome 65.0.3325.181 address bar showing https://1.1.1.1

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

Google Chrome 65.0.3325.181 address bar showing https://192.168.0.2

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

Certificate Viewer: *.cloudflare-dns.com

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?

  • 10
    Worth pointing out there is a huge difference between 192.168.0.2 and 1.1.1.1. One 192.168.0.2 doesn't exist outside of your intranet. If you created your own self-signed certificate 192.168.0.2 would be trusted, and you could use the same approach for the SAN, on a domain like fake.domain. Worth pointing out that 1.1.1.1 isn't a reserved IP address, so it appears, any CA would have issued the certificate. – Ramhound Apr 12 '18 at 4:54
  • 12
    blog.cloudflare.com/announcing-1111 "We're excited today to take another step toward that mission with the launch of 1.1.1.1 — the Internet's fastest, privacy-first consumer DNS service. " – user394804 Apr 12 '18 at 6:14
  • 11
    I think you bracketet the sentence wrong. They probably meant 'must revoke SSL certificates that use intranet (names or IP addresses)' not ''must revoke SSL certificates that use (intranet names) or IP addresses'. – Maciej Piechotka Apr 12 '18 at 7:47
  • 1
    @MaciejPiechotka is correct, this means "must revoke SSL certificates that use intranet names or intranet IP addresses" – Ben Apr 12 '18 at 11:53
  • 2
    BTW...there's no such thing as a mandatory revocation. Literally no organization on Earth has that kind of power. The closest you get is a bunch of CAs agreeing to do a thing. – cHao Apr 13 '18 at 21:39
92

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.

  • 4
    This answers exactly why I was confused. I sent a suggestion to GoDaddy to improve the wording of the article. Hopefully they'll fix it to clarify "(internal server name) or (reserved IP address)" as documented on CAB Forum. – Deltik Apr 12 '18 at 23:51
  • 11
    Pedantically, Cloudflare does not "own" the 1.1.1.1 address. It is owned by APNIC Labs, who gave Cloudflare permission to operate a DNS resolver there in exchange for Cloudflare's assistance in studying the large volume of garbage packets which are mistakenly addressed to that IP. – Kevin Apr 13 '18 at 20:18
  • 11
    Pedantically, @Kevin, APNIC doesn't own it either. This article mentions the issue of ownership, and uses the phrase "allocated to". IANA, part of ICANN, allocated the address range to APNIC who allocated such addresses to Cloudflare. IPv4 addresses are simply a fancy way of writing a number from 0-4294967296 (if you ping 16843009 in many operating systems then you'll find you get a response from 1.1.1.1) and the US won't recognize owning a number (hence why the name "Pentium" was made) – TOOGAM Apr 15 '18 at 3:05
  • 5
    The Intel thing was a case of trademark, not ownership… – StarWeaver Apr 15 '18 at 7:27
  • 3
    @TOOGAM: I mean that, in the whois system, which I specifically linked, 1.1.1.1 is allocated to APNIC Labs. If you're going to pick nits about allocation vs. ownership, don't twist the meaning of "allocated." – Kevin Apr 15 '18 at 15:09
100

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:

Certificate Viewer: Details: *.cloudflare-dns.com

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

  • Your article link does not appear to be working. Best to quote the relevant information. – Ramhound Apr 12 '18 at 4:53
  • 11
    I think it's not mistaken as much as misleading. It should be bracketet as 'must revoke SSL certificates that use intranet (names or IP addresses)' not ''must revoke SSL certificates that use (intranet names) or IP addresses'. – Maciej Piechotka Apr 12 '18 at 7:46
  • 3
    Well, it does say "intranet names or IP addresses". Intranet names, or intranet IP addresses. It's not wrong, it's just the OP only selectively read it. – Lightness Races in Orbit Apr 12 '18 at 10:25
43

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.

  • 1
    I don't see how this answers the question. Posting the content of a certificate doesn't explain why such a certificate could be delivered. – Dmitry Grigoryev Apr 12 '18 at 7:20
  • 18
    @DmitryGrigoryev: But it does prove that such a certificate was delivered, which was a major point of confusion in the question (the OP couldn't find 1.1.1.1 listed in the cert) – Lightness Races in Orbit Apr 12 '18 at 10:26
  • 3
    This answer does indeed answer the author's question. While the author went into more detail with regard to their confusion, this identifies the fact, the certificate in question is indeed valid. Since the author of the question, never provided us what GoDaddy actually said, difficult to answer the question with anythign else. – Ramhound Apr 12 '18 at 11:58
  • 4
    @DmitryGrigoryev - If the question is "Why does my browser think that 1.1.1.1 is secure?" (the title of this page) or "How is it possible that all the major browsers think that 1.1.1.1 is a trusted HTTPS website?" (the only actual question within the body), then "because 1.1.1.1 is listed as a SAN in the certificate" clearly answers that question. – Dave Sherohman Apr 15 '18 at 8:49
  • @DmitryGrigoryev "doesn't explain why such a certificate could be delivered" then the question is unclear, as it doesn't even contain the complete certificate information, and is not clearly either a technical question about TLS implementation in browsers or a policy question about CA, but a mix of both – curiousguy Jun 21 '18 at 5:20

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.