Domain validated HTTPS certs issued for google.com.mg and google.com.im
This isn't Google, but they're not fake - that's just what DV HTTPS is.
July 12, 2021
On November 5 2015, a CA trusted by your web browser issued SSL certificates for google.com.mg to someone that isn't Google.
On November 27 2015, a similar SSL certificate for google.com.im was issued.
The certificates aren't owned by Google and one of them has already been used for fraud, but they aren't ‘fake’ per se. They're just domain validated SSL certificates: encryption for whoever runs a domain, without any assurance that that domain belongs to a particular entity.
Even if the domain seems to match a particular company, domain validation makes no guarantee that the certificate has anything to do with that organisation. Sure, https://google.com.mg looks like https://google.com, but domain validation isn't claiming the former has anything to do with Google: just that domain-that-looks-like-Google-but-is-not can get your information without anyone else in the middle.
So: domain validated SSL makes no assurances about the identity of the certificate holder. Was this always the case? Didn't SSL used to mean something?
How we got here
Let's look at how we got here.
In the 90s, you had to prove who you were to get an SSL certificate, and it was a long slow process, involving faxing photocopies of ID and other documents. CAs would verify your identity and then sign a certificate. One even named themselves after that process.
As time went on and pressure between CAs increased, CAs started dropping the identity checks, eventually deciding that anyone who could receive admin email at a domain could get a certificate. Nobody would check that domain represented any particular company, even if it seemed like it did. This was called 'domain validated' (DV) SSL: it's encryption, without identity. As of January 2015 DV SSL was 70% of all SSL certificates on the internet.
Will automated checks save us?
CAs are required to check for ‘high risk’ certificate requests for all SSL certs. These checks are nearly always automated, and in this case seem to have failed: perhaps they weren't run, perhaps there's an implementation flaw in their regex. The CA that issued the 'google' certificate is relatively new, which may explain this. But what about the more established CAs?
If you've dealt with a CA you can probably get an idea of their level of tech awareness outside SSL: most CAs would know PayPal and include it in their self-maintained list of high risk sites. Most have never heard of Braintree, Stripe or TransferWise. Don't be surprised if the high risk checks doesn't catch any high trust company created in the last decade.
Did 'safe browsing' warnings affect the fake certificates?
If a site does bad things, people should report it and eventually the site will end up on safe browsing lists, hopefully before someone makes a bunch of money using the domain for fraud.
Let's see what happened in this case:
-
https://google.com.imhas been caught sometime after it was issued and added to a safe browsing warning list. - 66 days later
https://google.com.mgis still owned by not-Google, not revoked, and not on any 'safe browsing' warning lists. Edit: the DNS register has now deleted the domain after this article drew attention to the site.
Why can't we start verifying identities again?
We do. The real Paypal, Braintree, Stripe and TransferWise all have great big company names displayed at the top of your web browser, because their identity was actually verified and then included in the certificate. This is 'extended validation' (EV): a return to the original 90s vision of actually checking who people are. Fakes wouldn't pass the identity checks, and hence wouldn't show the identity.
If you're a web developer, ask a friend with an EV HTTPS cert if getting it was a massive pain in the butt. There's vague slow processes, some combination of federal/state and sometimes municipal governments, business directories like Dunn and Bradstreet, phone calls, lawyers and accountants. It's even worse if you live outside the US.
The standard time to deliver a cert is 7-10 days, and takes a massive amount of your time and your sanity in the process.
CertSimple was built specifically to fix the problem of identity checks for SSL. Our average delivery time is 5 hours. We're not the cheapest (and not the most expensive) but we are the fastest and most painless. Our tech is unlike any other EV provider. We check most of the details before you pay, use processes specifically adjusted to your company, and avoid lawyers and accountants completely.
If you want to prove your identity online, try us.