> From: owner-openssl-us...@openssl.org On Behalf Of jason.ting > Sent: Monday, 29 November, 2010 02:15
> >[server rejects client cert]. Look at the server CertReq to see > >if it is asking for particular CA(s) and if so whether the cert > >your client is using is issued by that CA (or one of them). > >Also check whether it is directly under or chained; > >if the latter I don't think commandline s_client can do it, > >although a (custom) app using the library can. > > I checked the server CertReq and from my little in depth knowledge of > OpenSSL and the TLS protocol it looks like it is not request > for a specific > certificate. > > read from 0xa3efa8 [0xa459fd] (15 bytes => 15 (0xF)) > 0000 - 0d 00 00 07 04 03 04 01-02 00 00 0e ............ > 000f - <SPACES/NULS> > <<< TLS 1.0 Handshake [length 000b], CertificateRequest > 0d 00 00 07 04 03 04 01 02 00 00 > <<< TLS 1.0 Handshake [length 0004], ServerHelloDone > 0e 00 00 00 > Yes, that CertReq has CA(name)s empty, thus not specifying any particular CA(s) it wants you to use. > The server certificate is chained but through my testing it > looks like it is > verified ok from the logs below SERVER cert isn't the problem. > >Remember that the client's issuer may be different from > >the server's issuer (whatever is in verisignVB.pem). > > In this case yes the client and server issuers are both different. The > Server certificate was issued under verisign and the client > is a self signed > certificate generated using OpenSSL > See below. > >Maybe their different client cert is under a different CA, > >which the server does like. > > So in this case is the problem caused by the server not able > to verify the > client certificate and hence rejecting the connection? Do I > just have to > ensure that the server has the correct client CA? > Yes, the server is rejecting the client cert because it doesn't 'know' (and trust) the client's issuing CA. > I have also attached the entire debug message and i changed > the command a > little to include the -verify depth. > > C:\Documents and Settings\jason.ting.GHL\Desktop\CBA SSL > Testing>openssl > s_client -verify 1 -connect > i2.paywide.nps.commbank.com.au:9001 -CAfile > verisignV.crt -cert L2009080526.crt -key L2009080526.key -debug -msg > http://old.nabble.com/file/p30328149/SSL%2BFail%2BLog.txt > SSL+Fail+Log.txt > According to that, your client cert isn't self-signed. It is apparently signed by the same company, which isn't the same thing; in X.509 and SSL, self-signed means that the cert Subject and Issuer,and specifically the subject KEY and the issuing/signing KEY, are EXACTLY the same. What you appear to have is your own 'private' or 'in-house' CA, which you used to sign a cert for your client. (Which OpenSSL can do, in several slightly different ways.) Either way, the server must trust the issuer of the client cert -- for a self-signed cert this is the client itself, and in your case it is an entity visibly CLOSE to the client. commbank.com.au sounds like a bank, and if so I wouldn't be very optimistic they will trust you to be a CA. If not, you'll have to get a client cert from a CA they do trust. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
