> From: owner-openssl-us...@openssl.org On Behalf Of plot.lost > Sent: Tuesday, 22 March, 2011 02:12
> 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. > > Yes and no. The server MAY specify desired client CAs in CertRequest, but OpenSSL client ignores this and uses whatever is configured as "own" key+cert. OpenSSL *server* can easily be misconfigured to solicit client certs that it doesn't trust and vice versa. And what any verifier does is its own choice. OpenSSL as verifier does always verify up to root, even if an intermediate CA cert is in the truststore; there have been several discussions in the past few months (here or -dev, I forget) about whether this is good. > >> I'm using a CAfile that has all of the certificates in - > as far as I > >> am aware that makes openssl trust these certificates. > >> CAfile is for you=client trusting the server, which is completely separate from the server trusting you. > > > > 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. > > -CAfile/load_verify_locations order doesn't matter. use_certificate_chain_file, for the certs you=client send to the server, order does or at least may matter. > Those running the server are the ones that signed the client > certificate > and provided the CA and Root certificates that are in use. > Okay, then they really should be trusting themselves! > == 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 As I said before, they *must* be configured with at least the root(s). They *cannot* trust (and must ignore) any root the client supplies. You must always supply your user cert, and prove its key. Whether you need to supply any intermediate certs (between you and root) varies. > chain and they then validate that using some other method. It > seems that > for some reason openssl is not sending any certificate to them. > Yes, you=client is definitely not sending the Cert (and CertVerify). Are you sure the server is sending the CertRequest? It should be just BEFORE the server "finished" (handshake 20 is really server_done). If the server doesn't send CertRequest, OpenSSL client mustn't and doesn't send any cert, and DOESN'T treat this as an error. Ooh, one thing I forgot before: does the TYPE of your key (in privatekey file and your cert) -- RSA, DSA/DH, ECDSA/DH -- match the negotiated ciphersuite? If not, OpenSSL musn't and won't use the cert for client auth. (And if the server demands client auth, it will reject, although as I have said before, "internal error" is a poor way for it to do so.) If the server is configured to agree to many (or all?) ciphers (and servers often are) you may need to _set_cipher_list to a more restricted set, or at least an ordering which puts your preference first. > This seems to be something specific to TLS1.1 - see: > > http://lists.foaf-project.org/pipermail/foaf-protocols/2009-Fe > bruary/000264.html > Not really. This is only if you *don't* have a requested cert, and IIRC the change is to send a Cert message with no cert (zero-length sequence) as opposed to no Cert message at all. The semantics, and the resulting trust decision, is the same. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
