Here is the ssl debug log : Upto line 3157, we have a successful transaction for a certificate containing ascii data.įrom line 3157, the server presented a certificate whose CA at client has non ascii data. It looks like our customer's wireshark log was incomplete and client authentication was enabled and after client sent certificateVerify packet, it failed. Certificate extensions: BasicConstraints,Critical SubjectKeyID,: Not Critical KeyUsage,: Not Critical Basic Contraints: CA, path length: not specified. Validity: Not Before: Tue Feb 14 09:00:, Not After: Sat Feb 14 09:00. n.v.,C=BE Issues Name: ST=Brabant, ,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. Subject Name: ST=Brabant, ,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. The hex value for é character is e9 which is displayed correctly in wireshark. Can you please help? wireshark log at : įrame 6 : server hello contains the certificate. I am clueless as to what is the exact failure of this SSL handshake. I have checked that the certificate has valid values for the non ascii character.
The SSL handshake works fine with a certificate that doesn't contain a non ascii character.
The client presents a certificate that is signed by this certificate. a) If the server returns an empty list of accepted client certificate signing certificate distinguished names (DNs), Salesforce will send the callouts. 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.
0 kommentar(er)
