Hello, I am working on an issue where the SSL handshake fails with a connection reset only when using a certificate that is added under trusted CA's at server that contains a non ascii character in issuer DN. The client presents a certificate that is signed by this certificate. The SSL handshake works fine with a certificate that doesn't contain a non ascii character. I have checked that the certificate has valid values for the non ascii character. I am clueless as to what is the exact failure of this SSL handshake. Can you please help? wireshark log at : http://www.filedropper.com/tcpdump03031320
The certificate data is : Serial Number: 30, 96. Subject Name: ST=Brabant,[email protected],L=B-1170 Brussels,TEL=+32 2 661 44 11,STREET=Terhulpsesteenweg 150 Chaussée de la Hulpe,CN=Portima PKI Root CA (Qualification),OU=Security,O=Portima s.c. n.v.,C=BE Issues Name: ST=Brabant,[email protected],L=B-1170 Brussels,TEL=+32 2 661 44 11,STREET=Terhulpsesteenweg 150 Chaussée de la Hulpe,CN=Portima PKI Root CA (Qualification),OU=Security,O=Portima s.c. n.v.,C=BE Version: X509 Version 3. Validity: Not Before: Tue Feb 14 09:00:00 EST 2006, Not After: Sat Feb 14 09:00:00 EST 2026. Basic Contraints: CA, path length: not specified. Key Usage: not critical. Certificate extensions: BasicConstraints,Critical SubjectKeyID,: Not Critical KeyUsage,: Not Critical It looks like our customer's wireshark log was incomplete and client authentication was enabled and after client sent certificateVerify packet, it failed. We captured these in ssl debug log. Here is the ssl debug log : http://www.filedropper.com/rsasdk Upto line 3157, we have a successful transaction for a certificate containing ascii data. From line 3157, the server presented a certificate whose CA at client has non ascii data. At line 3148 : ***WRITE ClientHello At line 3727 : ***READ ServerHello At line 3738 : *** Session created At line 3864 : ***READ Certificate chain At line 3976 : Found trusted certificate At line 4030 : ***READ ServerHelloDone At line 4042 : *** WRITE ClientKeyExchange RSA PreMasterSecret At line 4099 : ***WRITE ChangeCipherSpec At line 4134 : ***READ ChangeCipherSpec At line 4161 : ***WRITE Application Data At line 4269 : ***READ HelloRequest ( ?? I got a Read Application data packet for the successful one at this point) At line 4280 : ***WRITE ClientHello At line 4859 : ***READ ServerHello At line 4870 : *** Session created At line 4996 : ***READ Certificate chain At line 5108 : Found trusted certificate At line 5303 : ***READ CertificateRequest At line 5330 : ***READ ServerHelloDone At line 5432 : ***WRITE Certificate chain At line 5507 : *** WRITE ClientKeyExchange RSA PreMasterSecret At line 5558 : ***WRITE CertificateVerify At line 5832 : ***WRITE ChangeCipherSpec At line 5858 : ***WRITE Finished At line 5862 : ***SEND Alert Warning, Close Notify asked 01 Jun '14, 01:08  Mahathi Priya edited 02 Jun '14, 04:29 |
Frame 6 : server hello contains the certificate. The hex value for é character is e9 which is displayed correctly in wireshark.
One Answer:
Just a 'wild' guess: your client does not accept those characters, encoded as bmpString!? EDIT: After I had time to check the capture file, I don't believe it's a client problem. The client finishes the handshake and send encrypted data, which means it has accepted the cert and the chain. Furthermore, it's the server who closes the connection with a RESET. There must be another reason for the problem. Do you have access to the servers private key? If so, you can decrypt the capture file and check if there is anything "strange" in the communication. Otherwise, just check the logs of the server. Regards answered 01 Jun '14, 01:49  Kurt Knochner ♦ edited 01 Jun '14, 16:23 |
Thanks Kurt! I do not have access to the server's private key.But I had learnt that we can decrypt data if the session keys of this session had been exported.
I had initially thought that it had something to do with the certificate, because the server sends a RST only in this case. Yesterday I researched a bit on analyzing these packets and as you said, we are getting past the verification of the certificate. So probably it has nothing to do with the non-ascii character. I do not think the certificates plays a role later after the session key has been obtained through the handshake. As of now, I will try decrypting the data at server and look at the reason for sending a RST.
Thank you very much for your help!
Kurt, I think i had looked at the incomplete wireshark log. The ssl debug log tells that the client sends a "Alert Warning, Close Notify" after the certificate Verify phase.