On 22/03/2011 09:24, Crypto Sal wrote:
Me thinks they don't understand Client Authentication/Digital
Certificates. The server doesn't typically need to verify up to the
root, they provide a list of acceptable client CA names during the
handshake.
I'm using a CAfile that has all of the certificates in - as far as I
am aware that makes openssl trust these certificates.
Do you have them in reverse hierarchy when using '-CAfile'
?(Intermediate(s) to Root) I have seem some systems/programs flip out
because certificates were out of order.
Yes, they are in the usual order, with root as the final cert.
My thoughts...
When you connect using 's_client' do you use something similar to the
following?
`openssl s_client -connect FQDN:PORT -cert CERT_FILE -key KEY_FILE
-CAfile yourCAfile`
Have you tried just to connect to the site without the '-cert', '-key'
and/or '-CAfile' and see if any useful information is presented by the
server or does the connection fail outright?
Without the -CAfile then the connection to the server fails at the
server certificate stage (self-signed cert). With the CAfile but without
cert/key then the connection fails at the same point as if the cert/key
had been provided.
Based on the error of 'SSL alert number 80', that you have provided
previously, I suspect the problem is with your certificate's (client
cert) issuing CA being unknown to the server (one that it doesn't
directly trust and you need an appropriate hierarchy)
Those running the server are the ones that signed the client certificate
and provided the CA and Root certificates that are in use.
== Info: SSLv3, TLS handshake, Server finished (14):
<= Recv SSL data, 4 bytes (0x4)
0000: 0e 00 00 00 ....
== Info: SSLv3, TLS handshake, Client key exchange (16):
=> Send SSL data, 102 bytes (0x66)
0000: 10 00 00 62 00 60 45 1d e4 bd 03 4e bb 10 f1 04 ...b.`E....N....
0010: 72 4f 1f 2d 0e ea 7d d4 37 ee 4b a0 3f 27 33 26 rO.-..}.7.K.?'3&
0020: 33 10 06 82 4b 66 c0 ca aa 14 68 6a f8 00 0d 89 3...Kf....hj....
0030: 17 92 4e ed 84 eb 82 52 e8 59 39 fe 81 4b 7c 10 ..N....R.Y9..K|.
0040: e7 db 6e 54 2c 4e de 34 ff 8f 11 8e 5d 3e 5d e3 ..nT,N.4....]>].
0050: 41 09 b4 06 36 78 cd 4b 33 c2 ce e4 06 a4 19 97 A...6x.K3.......
0060: 5d bf 88 69 02 c8 ]..i..
== Info: SSLv3, TLS change cipher, Client hello (1):
=> Send SSL data, 1 bytes (0x1)
0000: 01 .
== Info: SSLv3, TLS handshake, Finished (20):
=> Send SSL data, 16 bytes (0x10)
0000: 14 00 00 0c 94 4e 6d 82 d8 f2 8b a0 0f 30 61 b3 .....Nm......0a.
== Info: SSLv3, TLS alert, Server hello (2):
<= Recv SSL data, 2 bytes (0x2)
0000: 02 50 .P
== Info: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert
internal error
== Info: Closing connection #0
I don't think they list any specific ca as part of the client cert
requests, I think they rely on the client providing a full certificate
chain and they then validate that using some other method. It seems that
for some reason openssl is not sending any certificate to them.
This seems to be something specific to TLS1.1 - see:
http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.html
Is this behaviour that is not supported by openssl, or am I going down
the wrong track (again...)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
