One might not want to make the client side interactive to the point where the user manages client side certs. Of course, that can be made automatic and predefined client certs could be embedded in the set-top box. Which might actually give one the advantage of knowing if the user is really using a set-top box on your approved list or not.
I am still confused with the original question about not wanting apache to give the cert out. That would be the server cert and the set-top client only needs trusted roots to verify this cert from apache. In fact, this design allows one to limit the circle of trust to servers that have certs signed by the embedded trusted root in the set-top box. Thanks Baber :) >>> [EMAIL PROTECTED] 04/18/02 09:26AM >>> "Tobias Mattsson" <[EMAIL PROTECTED]> writes: > Well it might not be such a good design, > but what I asked initially was only if it is possible to restrict apache from giving the cert out, and if that somehow can stop people from connecting to the server without having the certificate. No. This violates the SSL specification. > This is necessary since I am using a stripped SSL implementation on > the client side that does not support client authentication (The > clients will be Digital-TV set-top-boxes with OpenTV OS). I'm a little puzzled by this: the additional cost of adding client authentication TO THE CLIENT is very small. Essentially, it's being able to transmit two additional messages. Be better just to add client auth. Or, use passwords. -Ekr ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
