If that is the case, how does the following case work -
The Web Server cert (W) is actually given by an intermediate
certifying authority - say (I) - whose certificate in turn is
given by a well known certifying authority - say (V) (for Verisign).
Now clients are supposed to have the root CA certs for all the
well-known CAs like Verisign. But we cannot expect the clients to
have every (I) certificate out there.
So unless there is a cert chain, how is the client going to
authenticate the (W) cert ?
Maybe this is an academic question since in real life most (I)'s are
actually (V)'s and there are no real intermediate CAs.
Any information will be greatly appreciated.
Thanks!
Sent via Deja.com http://www.deja.com/
Before you buy.
By default, most servers assume the client has CA
Root certificates. This is the cause of the most
recent 1/1/2000 problem with older browsers:
verisign's root certificates expired so the
clients no longer have a complete chain. When you
use, for instance, Netscape 3.01, you get a
message saying the root CA has expired, even
though the server you've contacted via SSL has the
new root CA installed. To allow the server to send
the whole chain and the client accept it as
valid would also be a violation of the concept of
CA's, since one could therefore create their own
CA and the clients would be none the wiser.
> Maybe this is an academic question since in real
life most (I)'s are
> actually (V)'s and there are no real
intermediate CAs.
That would be an incorrect statement. Verisign
today ships I certs as standard, along with the
server cert. The I certs are authenticated by V,
but the server certs are authenticated by I. I
believe they're naming the I certs "Verisign Trust
Network", while the V cert is "Verisign Inc.". In
order to install these certs on IIS, you have to
run a particular utility (sgcinst.exe) to set up
the Intermediary trust and decode the pk7
certificate as delivered from Verisign.
Craig