Dear Victor, thanks for your help. The problem is that I need to understand OpenSSL and its mechanisms and possibilities in order to find a way to implement the design of the protocol. It would be nice if you could help a little bit further still, but I will understand if you should choose not to.
you compare the enclosed peer certificate (public key fingerprint) with the > peer certificate (public key fingerprint) from the SSL session. > I wrote a customized "check certificate" method, that simply compares the certificate the client offered during the connection build up, to the certificate we know it should be using. This works fine. However I think it would be more secure to be able to verify that the client is actually in posession of the private key belonging to this certificate, right? The protocol design, as I should implement it, however does not speak about signing a part of the payload with this private key; else it would be easy for me to do. That is why I hope to find some OpenSSL mechanism, that would allow me to do that independent of the payload. Thank you for your help and your time, and sorry for not yet understanding everything perfectly. Michael On Thu, Sep 24, 2009 at 8:20 PM, Victor Duchovni < victor.ducho...@morganstanley.com> wrote: > On Thu, Sep 24, 2009 at 08:03:49PM +0200, Michael Prinzinger wrote: > > > Dear Victor, > > > > it is almost working. > > with the cerify_callback function returning 1, I can establish a > connection. > > However when I call SSL_get_verify_result() it tells me the certificate > is > > not in the trust store. > > You don't care. Don't bother with SSL_get_verify_result() it is of > no consequence. You need to compare the certificate *directly* against > what you expected to receive. > > Or your agreement that I understood your problem is in error. > > I think I need to stop here. You are still asking API questions, when > you still don't have a design and are struggling with related security > principles. > > You are not yet ready to write the code. First solve the problem "on > paper" with a design, that is written in words, not computer code > and relates the security steps taken to the security requirements > of the protocol and application use-case. > > -- > > /"\ ASCII RIBBON NOTICE: If received in error, > \ / CAMPAIGN Victor Duchovni please destroy and notify > X AGAINST IT Security, sender. Sender does not waive > / \ HTML MAIL Morgan Stanley confidentiality or privilege, > and use is prohibited. >
