thanks martin. i made the changes and now im getting Verify return code: 19 (self signed certificate in certificate chain)
is this ok, or i need code 0 On Thu, Jan 9, 2014 at 1:33 PM, Martin Hecht <he...@hlrs.de> wrote: > I was thinking about manual verification of certificates on the command > line. From what you wrote now, it seems that you are using some calls to > the openssl library in a client-server application, maybe via other > tools/webserver or so, and I understand that the server certificate was > issued by a different CA from the one which issued the client > certificate. If that's the case you need to declare the CA certificate > of the "other side" as trusted. In other words the client must trust the > CA which issued the server certificate, and (if you use a client > certificate for authentication) the server must trust the CA which has > issued the client certificate. You can trust a specific CA by copying > the CA certificate into the certs directory which can be configured in > openssl.cnf (on my Linux host the file is /etc/ssl/openssl.cnf which can > be configured at compile time and the certs directory configured in this > file is /etc/ssl/certs). > > On 09.01.2014 06:59, Yvonne Wambui wrote: > > thanks martin, your response shade some light and i can now understand > what > > im doing. Im trying to create a two way ssl connection, the problem when > > verifying the connection to the server, its using my RootCA instead of > the > > server, hence throwing verification error 19. would you please advise on > > what might be wrong > > > > > > On Wed, Jan 8, 2014 at 8:27 PM, Martin Hecht <he...@hlrs.de> wrote: > > > >> On 08.01.2014 15:32, Yvonne Wambui wrote: > >>> i get this error when verifing a non-self signed certificate. how do i > >> make > >>> it not point to the rootCA > >>> > >> It makes no sense to verify a non-self signed certificate without the > >> rootCA certificate. To verify such a certificate you have to provide the > >> certificate chain (which might be just one issuing CA, but often also > >> some intermediate sub-CAs). A set of trusted CA certificates is provided > >> by the distributions (most browsers bring their own collection of CA > >> certificates). If the CA which has issued the certificate you are trying > >> to verify is not included there, you can provide it on the command line > >> for the openssl command or manually copy it into the folder your > >> distribution is using, or you collect all your private trusted > >> certificates in a folder which you manage. Depending which option you > >> choose, you can specify the details when calling openssl verify by the > >> parameters -CAfile or -CApath. You don't have to trust the intermediate > >> CA's explicitly, but you have to provide the certificates if there are > >> some (that's the -untrusted parameter). For details see the man page of > >> the verify utility. > >> > >> > >