The EFF SSL Observatory

Posted Aug 6, 2010 18:05 UTC (Fri) by HenrikH (subscriber, #31152)
In reply to: The EFF SSL Observatory by JoeBuck
Parent article: The EFF SSL Observatory

Yes it should be an error and thankfully it is. SSL does not protect the ip of the machine, it rather protects the name of the site, the name that it presents to the user via the URL.

Multihomed web servers would be impossible to secure with your scheme of accepting the cert for site.com just because it was given to me by the site sitte.com which resolves to the same ip. I hope you see the problem with that.

For situations like the one you described it's better to buy wildcard certificates since you then can use the same certificate for *.domain.com

Unfortunately a wildcard cert for *.domain.com does not protect domain.com itself though, perhaps for good reasons I don't know.

The EFF SSL Observatory

Posted Aug 6, 2010 18:11 UTC (Fri) by flewellyn (subscriber, #5047) [Link]

>Unfortunately a wildcard cert for *.domain.com does not protect domain.com itself though, perhaps for good reasons I don't know.

Yes, it does. I have seen this in action.

The EFF SSL Observatory

Posted Aug 7, 2010 5:02 UTC (Sat) by alankila (guest, #47141) [Link]

Subject alternative name can be set to two values: domain.com, *.domain.com.

The EFF SSL Observatory

Posted Aug 15, 2010 15:16 UTC (Sun) by kleptog (subscriber, #1183) [Link]

While it's OK to give an error, it should not require you to click half a dozen times to accept the certificate, which will then be permanently trusted. Instead it should see that the name in the certificate resolves to the same IP you're looking at and offer to connect you to that site instead.

Hell, I'll take an automatic redirect. Anything is better than the adding of lots of implicitly trusted certificates to your store when you don't actually know them from a bar of soap. That would be nice in situations where machines have lots of CNAMEs.