I don't know what exactly you are doing, so it is difficult to speculate why you are receiving code 19.
Some information is exchanged during establishment of the ssl connection. For example if you have a web server and a browser, the web server shows the host certificate to the browser and the browser has to verify it. Browsers don't have all certificates in their certificate store, but they have the trusted root-CA certs. So it is up to the web server to deliver the whole chain (including the sub-CA certificates). Then, the browser checks, if the host certificate matches the hostname, if the host certificate is issued by the intermediate CA, if the intermediate CA cert is issued by a superior CA, and so on, until it finds a self-singed CA certificate. That's the root CA certificate. Now, the browser checks if that particular rootCA certificate is among the ones the browser has configured as trusted root-CAs. In order to quickly find the correct file in the directory, it calculates the hash on the certificate's subject and looks for such a file. If it finds one and it is the same certificate, then it has successfully verified the chain and verified that the CA is trustworthy. There are some more advanced things like checking that none of the certificates has expired, that the revocation lists are up to date and the certificates have not been revoked, but I'd ignore this for the moment. In your case all certificates have been found (either in a local directory or they have been transmitted during establishment of the connection), but the last step to find the rootCA certificate among the trusted certificates did not succeed. It could as well be that your application has its own certificate store (like Mozilla browsers or Tomcat web server for instance). On 09.01.2014 14:52, Yvonne Wambui wrote: > 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. >>>>>> >> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
