could you please explain the last reason.
On Thu, Jan 9, 2014 at 3:38 PM, Martin Hecht <he...@hlrs.de> wrote: > X509_V_OK would be code 0 > 19 means that the CA certificate could be found, the chain could be > built and verified completely up to the CA certificate but the latter is > not trusted. (see http://www.openssl.org/docs/apps/verify.html) > ah, for some things to work correctly, the file name must be the subject > hash of the CA certificate appended by ".0" but I'm not sure if this is > the cause for code 19 here. Might as well be that by accident you have > copied the server or client cert instead of the issuing CA cert or > something like that... > > On 09.01.2014 13:04, Yvonne Wambui wrote: > > 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. > >>>> > >
