Re: simple question about certificate chains

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 07/06/05


Date: Wed, 6 Jul 2005 07:13:37 -0400


"Richard E. Silverman" <res@qoxp.net> wrote in message
news:m2acl1o4yz.fsf@darwin.oankali.net...

> No, browsers generally do *not* do this, for several reasons. The most
> obvious is that, since the DNS is insecure, it would be easy to get a
> client to incorrectly accept a certificate by simply spoofing its DNS
> traffic. Browsers should (and generally do) match the certificate against
> what the user types, nothing else -- that's the point, to verify that
> you're connecting to the site you intended. It's also why aliases don't
> work -- for example, suppose a site's certificate says www.foo.com, but
> the server is reachable at foo.com as well. If you connect to
> https://foo.com/ the browser will give a warning; it's up to you to decide
> that a certificate with the name "www.foo.com" just as acceptable in this
> case.

And 99% of people will simply click on and accept that SSL key after that
warning, especially self-signed keys. The top-down chain of authoritty for
accepting signed SSL keys is fairly broken in that sense.

> In any event, to answer the original question: certificate you get from
> Verisign or whomever will not have the CA bit set, and hence no one will
> trust a further certificate you sign with its key. The only way to get a
> CA certificate from such an entity will be to enter into a legal agreement
> stipulating that you *won't* do things like issue bogus certificates for
> domains you don't own.

Also stealing it or abusing someone else's rootkitted server to steal the
keys. Given the traffic in zombied machines for sending spam, I'd be quite
surprised if there's not a healthy traffic in cheap SSL keys stolen from
poorly secured companies computers, especially university sites.