I'm trying to connect to an HTTPS server, and my connection is being
rejected when I use a client certificate:
[dw...@macbook ~]$ openssl s_client -cert $CERT -connect $SERVER:443 -crlf -tls1
CONNECTED(00000003)
depth=1 /C=US/O=Foo Corporation/CN=Foo Intranet Basic Issuing CA 2A
verify error:num=20:unable to get local issuer certificate
verify return:0
24620:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:530:
Making the _same_ connection with curl (built to use NSS) is working.
Looking at a packet capture, the only obvious difference I see is in the
structure of the packet which we send with our client certificate.
Looking at the OpenSSL traffic in wireshark, it looks like this:
- Secure Socket Layer
- TLSv1 Record Layer: Handshake Protocol: Certificate
- Secure Socket Layer
- TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
- TLSv1 Record Layer: Handshake Protocol: Certificate Verify
- TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
- TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
The one from NSS that _works_ looks like this:
- Secure Socket Layer
- TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages
- Handshake Protocol: Certificate
- Handshake Protocol: Client Key Exchange
- Handshake Protocol: Certificate Verify
- Secure Socket Layer
- TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
- TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
Is it possible that the server would be objecting to the fact that the
Certificate/Client Key Exchange/Certificate Verify messages from OpenSSL
aren't all in the same TLSv1 record?
There's another distinction which I don't understand -- why is wireshark
grouping TLSv1 records under 'Secure Socket Layer' heading, and how does
it decide where one 'Secure Socket Layer' object ends and the next one
starts?
I've given a screenshot of wireshark's display at
http://david.woodhou.se/handshake.png in case the above description
doesn't do it justice. The working connection with NSS is on the right;
the failing connection with OpenSSL is on the left.
This happens for me with 0.9.8f, 0.9.8k and 1.0.0-beta2 at least; I
didn't try any more versions. The server is some Cisco VPN box, but for
the purpose of this discussion it's just an HTTPS server (and firefox
works with it too).
When I _don't_ use a client certificate, I can connect fine -- of course
I can't authenticate, but at least the HTTP exchange works well enough
to tell me to sod off.
It's only when I use a certificate that it will reject my connection
completely. I get an ACK to my packet described above, then a FIN.
That's it.
The certificate in both cases is the same.
--
dwmw2
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
