The authors of the page you are referring to fail to understand some basic concepts and make otherwise false statements. Because of that I don't think that you should take any statements or conclusions from this article for real. Some examples:
This certificate identifies itself (via CN field) as *.google.com despite being served during a putative session with google.fr (again, this kind of obvious certificate misconfiguration is all but impossible to imagine google doing in production systems):
While the certificate they cite has *.google.com
as the CN as they correctly state they fail to recognize that the certificate contains *.google.fr
in the subject alternative names (SAN) section. And obviously the authors don't know that if this section is present and contains DNS names like in this case then the browsers should not even look at the CN but only at the SAN. This means the certificate is matching the server and the trust chain is also correct, so it is no wonder that the browser does not complain about it.
However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example: ...
I don't know which "other services" they refer too but neither google.com nor youtube.com use EV certificates.
In summary: There are several obvious errors in this article. Therefore I recommend to simply ignore any statements and conclusions made in this article because the authors don't seem to understand what they are talking about.
Edit: I just found that this article is also heavily critized at https://news.ycombinator.com/item?id=10030820