Domain validated SSL certs for google.com.mg and google.com.im (not Google)
1–10 of 27 posts
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#2Author here. As the article mentions, this is how DV SSL works. The issue is that most people outside tech are conditioned to trust DV identifiers.
As a side note, newer versions of Chrome have stopped using 'identity' for domain validated certificates.
A domain validated cert in Chrome in 47.0.2526.106 http://i.imgur.com/RiISSrU.png
A domain validated cert in Chrome 49.0.2618.0 no longer refers to 'identity' http://i.imgur.com/XkaPDwx.png
The term 'identity' remains in use with extended validation certs - http://imgur.com/j7fKGt1
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#366 days later google.com.mg is still owned by not-Google, not revoked, and not on any 'safe browsing' warning lists.
So? Why would a website be in safe browsing warning lists if it doesn't do anything malicious? Does Google own a trademark in Madagascar? If so, they probably can take down this domain by asking NIC-MG. If not, then, unless this website is used for phishing, I don't see any problems with issuing a certificate.
(It's interesting how companies selling certificates switched to scare tactics after Let's Encrypt made DV certs free.)
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#4I don't get the tone of the article. Why is this a bad thing?
It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark.
I actually find this to be a good thing that someone was able to get a domain, create an SSL certificate for it painlessly and start securing traffic between clients and their web property without having to spend a) tons of money and b) tons of time dealing with antiquated CAs that should be entirely automated.
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#566 days later google.com.mg is still owned by not-Google, not revoked, and not on any 'safe browsing' warning lists. So? Why would a website be in safe browsing warning lists if it doesn't do anything malicious? Does Google own a trademark in Madagascar? If so, they probably can take down this domain by asking NIC-MG. If not, then, unless this website is used for phishing, I don't see any problems with issuing a cert…
[deleted]
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#6I don't get the tone of the article. Why is this a bad thing? It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark. I actually find this to be a good thing that someone was able to get a domain, crea…
The tone of the article is such because the company writing it only sells EV certs and therefore is on a relentless quest to discredit DV certs as inferior.
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#7I don't get the tone of the article. Why is this a bad thing? It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark. I actually find this to be a good thing that someone was able to get a domain, crea…
And furthermore, you shouldn't need to get your identity verified and send in pictures of your ID just to make a website, blog, or custom email domain.
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#8I don't get the tone of the article. Why is this a bad thing? It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark. I actually find this to be a good thing that someone was able to get a domain, crea…
The tone of the article is such because the company writing it only sells EV certs and therefore is on a relentless quest to discredit DV certs as inferior.
Author here: DV certificates are inferior. Knowing whose key you're encrypting with is a good thing. DNS providers do not do identity checks.
Edit: 100% agreed with laumars' point below regarding blogs and low trust sites. DV certificates have their place, it's just that high trust websites aren't it. I've added an author tag as requested.
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#9So everything is working as intended? Great!
Re: Domain validated SSL certs for google.com.mg and google.com.im (not Google)
#10I don't get the tone of the article. Why is this a bad thing? It's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be. That falls to the domain registrar, if you have a problem with someone owning google.com.mg go take it up with the registrar or better yet leave it up to Google as it's THEIR trademark. I actually find this to be a good thing that someone was able to get a domain, crea…
> it's not the job of SSL to ensure a domain name is not owned by someone it shouldn't be.
That's correct. CAs checked identity back in the 90s, but stopped and moved to domain validation for most certificates. The article mentions explicitly: the certificates aren't fake, they're just DV, and that's what DV is. Obviously most consumers have no idea about that, and have been conditioned to trust any kind of SSL.
The main issue asides from most consumers having no idea what DV is, is that Section 4.2 of the baseline requirements - which applies to all CAs - asks CAs to check for 'high risk' domains. That's clearly broken here.
Certificate transparency records for the domains in question: