> From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout > Sent: Saturday, 10 March, 2012 02:33 > To: openssl-users@openssl.org > Subject: Re: Please Clarify : Unable to verify leaf signature (21) > > > Thanks Dave. > > I request you please give more information regarding this error. What > exactly it means to me ? > It's (almost, see below) a local error from OpenSSL client when it can't verify the server-cert (with server verification enabled and a nonanonymous ciphersuite selected).
> I am doing Server Authentication where i keep ROOT cert are > my client and > Server cert ( could be Selfsigned or chained cert). > The examples you gave before are *directly* signed/issued (CA -> server) versus chained. *Selfsigned* is different; that means a server (or other EE) cert that signs itself, with no CA at all. > The issue here is i am facing the below error when ever i am using > 2-level-CA cert even more. > > Alert Level: Fatal, Description: Unable to verify leaf signature (21) > > > Due to my limited knowledge hence I am not sure whether I am > using correct > command to generate Chained Hirerchy. Please guide me or suggest me. > What you show is *a* way to create such a hierarchy in OpenSSL, but not the *only* way to do so. > I am creating a 3-Level-CA like this : rootCA---> ServerCA--- > >ServerCA1----- > Server. > > i.e. server cert >>> intermediate CA1 >>> intermediate CA2 > >>> root CA > > Here are the commands > <reformatted and trimmed> Note: uppercase program names normally occur only on Windows which normally doesn't have cat (or CAT). I'll assume you have some port with the usual functionality, not something weird. > OPENSSL req -newkey rsa:1024 -sha1 -keyout rootkey.pem > -out rootreq.pem -config root.cnf > OPENSSL x509 -req -in rootreq.pem -sha1 -extfile root.cnf > -extensions certificate_extensions -signkey rootkey.pem > -out rootcert.pem > CAT rootcert.pem rootkey.pem >root.pem > I assume you have correct values (particularly distinct names and the right extensions) in each of your .cnf files. And all commands executed successfully. > <similar for serverCAkey&cert under root> > CAT serverCAcert.pem serverCAkey.pem rootcert.pem >serverCA.pem > <ditto serverCA1 under serverCA> > CAT serverCAcert1.pem serverCAkey1.pem serverCAcert.pem > rootcert.pem >serverCA1.pem Note: you don't actually need higher certs here for the intermediate CAs. No function ever needs both key and chain for a CA (unlike an EE). But it should do no harm as long as the correct (same-level) cert is first, as you indicate. > <ditto server under serverCA1> > CAT servercert.pem serverkey.pem serverCAcert1.pem > serverCAcert.pem rootcert.pem >server.pem > > I used root.pem at Client Side and Server.pem at Server > Side. But i am seeing the error > Alert Level: Fatal, Description: Unable to verify leaf signature (21) > Used how? Assuming as I said before a server using OpenSSL: If you use that server.pem file as the chain-file for the server, it will send the whole chain and the client should verify (as long as it has the root, which you say it does). If it doesn't, try getting a line trace (e.g. wireshark) or a detail log. If your client program can't do detail log, use openssl s_client with -showcerts (in addition to at least -connect and -CAfile/-CApath, more if needed). But if you use that file as the cert-file for the server, it will send only the EE cert and the client will fail to verify, with OpenSSL verify error 21. (The SSL/TLS alert values are different, so I assume the 'alert' you report is some kind of local-program alert not a SSL/TLS alert on the wire. And it says 'leaf' rather than 'first', which is semantically equivalent but not the actual string in OpenSSL.) If you use servercert.pem as the cert-file for the server and also a file containing serverCA1.pem and serverCA.pem (and optionally but not required root.pem) as the CA-file for the server, that will also serve the chain, and the client should verify. In addition CA-file will control what *client* certs are accepted by the *server* if you use client authentication, which you haven't mentioned. Finally, you can use servercert.pem as cert-file with a CA-directory which contains (at least) serverCA.pem and serverCA1.pem under correct hash names. That's a little more complicated, so leave it aside for now. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
