Yep, from X509_verify_cert() source code I think it will work correctly
without main CA if your certs are self signed -- when verifying, OpenSSL
just builds a certificate chain ending with a trusted self-signed cert:
- on server you need to load all clients certs with
SSL_CTX_load_verify_locations();
- on each client you need to load server's cert the same way.
During verify OpenSSL will detect that provided [by another side] cert
is a self-signed one and try to find the same trusted cert in it's
store. If it fails, error
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT is reported.
On Mon, 2012-06-04 at 15:53 +0530, Lloyd wrote:
> Thanks again...
>
> In my case I am using "SELF SIGNED CERTIFICATES", totally eliminating
> CA. So, is it possible to check both sides without a CA?
>
> Thanks for your help....
>
> Lloyd
>
> On Mon, Jun 4, 2012 at 3:45 PM, Alexander Komyagin <[email protected]> wrote:
> > If you need checks on both sides, both client and server shall have
> > loaded their own certificates (private/public keys) and some CA
> > certificate(s) to be verified against.
> >
> > SSL_CTX_load_verify_locations() loads locations where CA certs are
> > stored.
> >
> > Take a look at
> > http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html
> >
> > On Mon, 2012-06-04 at 15:14 +0530, Lloyd wrote:
> >> Thanks Alexander Komyagin,
> >>
> >> So it means in mutual authentication mode also, each client and server
> >> need only to load its only private key and public key. During SSL
> >> handshake the SSL protocol will share the public keys of each other?
> >>
> >> Then whats the use of "SSL_CTX_load_verify_locations()" API?
> >>
> >> In my case the client need to authenticate server and also the server
> >> need to authenticate client.
> >>
> >> Thanks again,
> >> Lloyd
> >>
> >>
> >> On Mon, Jun 4, 2012 at 2:57 PM, Alexander Komyagin <[email protected]>
> >> wrote:
> >> >
> >> > Hi, Lloyd!
> >> >
> >> > If you are establishing SSL connection between client and server, and
> >> > SSL_VERIFY_PEER flag is set, AFAIK server will ask for client
> >> > certificate during SSL handshake phase.
> >> >
> >> > So why do you need to load clients certs manually?
> >> >
> >> > On Mon, 2012-06-04 at 11:06 +0530, Lloyd wrote:
> >> > > Hi,
> >> > >
> >> > > We have a client server application with SSL (open ssl). The server
> >> > > has a public/private key pair and also "each client" has a
> >> > > public/private key pair. When client and server communicates they need
> >> > > to authenticate each other. So we are using the flags SSL_VERIFY_PEER|
> >> > > SSL_VERIFY_FAIL_IF_NO_PEER_CERT at both the client and server. All the
> >> > > certificates are self signed.
> >> > >
> >> > > Each client is unique, that is each of them has its own private/public
> >> > > key pair. In order to verify each client, the server needs to load all
> >> > > the clients certificates (isn't certificate mean public key in this
> >> > > context?),. Is it possible to load all client certificate? which
> >> > > openSSL api shoud I use ffor this?
> >> > >
> >> > > Thanks a lot,
> >> > >
> >> > > Lloyd
> >> > >
> >> > >
> >> >
> >> > --
> >> > Best wishes,
> >> > Alexander Komyagin
> >> >
> >> ______________________________________________________________________
> >> OpenSSL Project http://www.openssl.org
> >> User Support Mailing List [email protected]
> >> Automated List Manager [email protected]
> >
> > --
> > Best wishes,
> > Alexander Komyagin
> >
> > ______________________________________________________________________
> > 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]
--
Best wishes,
Alexander Komyagin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
