Erwann ABALEA wrote: >But to me it seems that enhancing access restriction using the server cert >is not a good idea. That means the server cert is a secret known only by >the trusted users. By definition, a certificate is public, so it cannot be >a secret. > > Basically, this means that the client is truly doing password based authentification, and that the password is the certificate of the server.
Not going into that and doing standard user/password authentification will be a lot simpler, and more secure as each user will be able to have his own password. Shared password is about the worst you can imagine in security. That's what I meant by "even if you manage to do it, it won't bring anything more than the above solution". And we still haven't proved it's feasable, this would mean modifying the SSL stack of the client so that it accepts a connexion without receving the certificate of the server, and use instead a copy of the certificate from somewhere else to continue the transaction. No standard SSL stack will be able to do that, if modifying the stack for this is possible, you could as well modify it to do proper user certificate authentification. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
