When I go to https://www.schneier.com/, everything works normal. As soon as I access the same site using its IP address (, I get a security warning (even if I write something like

The same is not true for google.com (I'm using this IP address:

Why is that? How are these two sites different?

UPD: Here's the GIF of what I see when entering Google's IP, no warning there: http://www.giphy.com/gifs/26gYMNRlBYy9yAYnu

  • 10
    the HTTPS cert names a domain, which mis-matches an IP address, even if that IP maps to the domain. Otherwise, sites couldn't change IPs without re-issuing certs; yuck.
    – dandavis
    Jan 11, 2017 at 18:33
  • 4
    "The same is not true for google.com" Yes it is: If you use the http site obviously it doesn't happen, but you're navigating to for schneier.com, so if you want comparable results you'll have to use for google.com.
    – Ajedi32
    Jan 11, 2017 at 20:08
  • Because his site was explicitly configured (*or misconfigured?) to do that. Jan 11, 2017 at 23:22

4 Answers 4


It's because you generally create a TLS Certificate for an hostname, not an IP. Changing IP addresses is trivial, changing domains are not that common.

If you open the site in Firefox using IP, you will see this message: uses an invalid security certificate. 

The certificate is only valid for the following names:
 schneier.com, www.schneier.com 

Opening (Google) will give the same message.

  • Strange, but opening most certainly doesn't give me the same message on my computer both in Firefox and Chrome. Jan 11, 2017 at 18:38
  • 1
    You accessed Google's IP using HTTP or HTTPS?
    – ThoriumBR
    Jan 11, 2017 at 18:41
  • I just copied and pasted the IP, the same way I did with Schneier's IP. Google redirected me to HTTPS. Jan 11, 2017 at 18:45
  • 1
    @PaulVergeev try curl -LI (my result: paste.ubuntu.com/23784846). Google first redirects from the IP to http://www.google.com and then to the local Google site. In Chrome, because Google uses HSTS, the browser does a 307 redirect to the HTTPS site when it encounters the first redirect: i.stack.imgur.com/MkgWJ.png Schneier's site simply redirects to HTTPS, not to a particular domain.
    – muru
    Jan 12, 2017 at 2:23
  • @muru Thank you, this explains a lot! Together with your comment, the answer is complete. Jan 12, 2017 at 14:22

The error indicates that you have reached a site that cannot prove it owns the address that you entered in the address bar.

Imagine this. You visit https://www.google.com. You check the certificate for the connection and discover that it was actually issued to www.DeathToAmerica.ru. This is a strong indication that your browser hasn't actually reached google.com. Instead, your communications have been intercepted in what is known as a Man in the Middle(MitM) Attack. Your communications are still encrypted, but they are being sent to (and decrypted by) an unknown entity.

To protect against this, your browser will automatically check the address that you entered against the certificate. Whenever they do not match, it will display the error that you are seeing.

Since you entered but the certificate was issued to www.schneier.com you will get the error. This indicates that the site you have reached cannot prove that it owns

Generally speaking, a CA will not issue a cert for an IP address. If you need to access a site that is not in DNS, and you must use https, and you don't want to see that error, I suggest you use a host entry.

  • Thank you for a thorough answer, but I still don't get it: how is google different? I've took a screenshot (giphy.com/gifs/26gYMNRlBYy9yAYnu) to show that there's no warning whatsoever for me. (By the way, thank you, got a good laugh from "deathtoamerica.ru"). Jan 11, 2017 at 19:05
  • In your animated GIF, I can see that the IP address is redirecting your browser to https://google.ru, which apparently has a valid certificate that matches its address.
    – John Wu
    Jan 11, 2017 at 19:23
  • 2
    @PaulVergeev You didn't type the https. If you go to you will get the same error.
    – tlng05
    Jan 11, 2017 at 19:29

The certificate is issued to a common name (CN), in your example schneier.com / *.google.com.

If you access the website using the IP address instead of the domain name this CN field will not match the authority part of your URL and your browser will return an error (like NET::ERR_CERT_COMMON_NAME_INVALID for Google Chrome).

If you are accessing the websites you mentioned via http, you are being redirected to the https equivalent. However, Google will redirect you to https://google.com whereas Schneier will redirect you to The former will not cause an error, the latter will (due to the reasons mentioned above).

So the effect you described is due to the configuration of the redirects on the two web servers.

  • 1
    If you access (without TLS) google issues a redirect to https://www.google.com, which might explain why some users perceive that there is no error.
    – John Wu
    Jan 11, 2017 at 18:43
  • I've added a GIF that shows my screen when I do that. Jan 11, 2017 at 18:49
  • @JohnWu Why only some users? Jan 11, 2017 at 18:50
  • Because some users are smarter than others.
    – John Wu
    Jan 11, 2017 at 19:01
  • I missed the fact that you are accessing the websites via http and being redirected to https. If you do so Google will redirect you to https://google.com whereas Schneier will redirect you to The former will not cause an error, the latter will (due to the reasons I mentioned). I will adjust my answer accordingly.
    – Hacktiker
    Jan 11, 2017 at 19:18

Most major accepted TLS/SSL certificates are issued to host names, which can be looked up via DNS.

The reason for this checking is to prevent potential Man in the Middle attacks, where an attack could have a perfectly valid certificate, but it isn't issued to the website you are attempting to visit. Certificates address the area of "non-repudiation".

In the case with google, they attempt to redirect users to the domain name as the IP address hosting the web service likely handles requests for many domain names (see the second code box below). The same thing would happen if you attempted to access a website which uses Cloudflare. Because Cloudflare is sitting in front of many websites, it doesn't know which to serve, and returns an error message. uses an invalid security certificate.
The certificate is only valid for the following names:
schneier.com, www.schneier.com

Google will give the same error code: uses an invalid security certificate.
The certificate is only valid for the following names:
*.google.com, *.android.com, *.appengine.google.com, *.cloud.google.com, *.google-analytics.com, *.google.ca, *.google.cl, *.google.co.in, *.google.co.jp, *.google.co.uk, *.google.com.ar, *.google.com.au, *.google.com.br, *.google.com.co, *.google.com.mx, *.google.com.tr, *.google.com.vn, *.google.de, *.google.es, *.google.fr, *.google.hu, *.google.it, *.google.nl, *.google.pl, *.google.pt, *.googleadapis.com, *.googleapis.cn, *.googlecommerce.com, *.googlevideo.com, *.gstatic.cn, *.gstatic.com, *.gvt1.com, *.gvt2.com, *.metric.gstatic.com, *.urchin.com, *.url.google.com, *.youtube-nocookie.com, *.youtube.com, *.youtubeeducation.com, *.ytimg.com, android.clients.google.com, android.com, developer.android.google.cn, g.co, goo.gl, google-analytics.com, google.com, googlecommerce.com, urchin.com, www.goo.gl, youtu.be, youtube.com, youtubeeducation.com


An image of what would happen when you access a site "protected" by cloudflare:

Cloudflare via IP

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .