Hi Wan-Teh, Nelson, could it be that this error is also raised by the client if the client can not 'participate' in ssl client-auth?

Unfortunately I only got a text-output of 'ssldump', not sure if this is would be helpful.

The end of the handshake shows ...

1a0: f3 6e fc 04  ab 79 e1 13                            | .n...y..
   0: 0d 00 2b 36                                         | ..+6
      type = 13 (certificate_request)
      length = 11062 (0x002b36)
         CertificateRequest {
            certificate types[3] = { 01 02 40 }
            certificate_authorities[11056] = {

                <<<<<....List Truncated....>>>>>

            }
         }
   0: 0e 00 00 00                                         | ....
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(7 bytes of 2)
SSLRecord { [Mon May 14 13:25:27 2012]
   0: 15 03 00 00  02                                     | .....
   type    = 21 (alert)
   version = { 3,0 }
   length  = 2 (0x2)
   fatal: bad_certificate
   0: 02 2a                                               | .*
}


Interestingly enough the community member told be that this error does not happen with

NSS:  3.12.8
NSPR:  4.8.6


TIA,
Bernhard

Am 5/9/12 7:43 PM, schrieb Wan-Teh Chang:
On Tue, May 8, 2012 at 7:33 PM, Nelson B Bolyard<nel...@bolyard.me>  wrote:

Bernhard,
I think the most likely explanations are these:

1) Server certificate has a public key that is too small, too large, has a
too small public exponent (if RSA), an unknown key type, or a key for an
Elliptic Curve that is not supported by NSS.

2) Some other certificate in the server's cert chain has one of the above
problems.

3) The server is attempting to use "Server Key Exchange" for forward
secrecy, and the key it is offering for that purpose has one of the problems
mentioned above.

4) The server is selecting a cipher suite that is incompatible with the type
of key in its public key certificate.

Nelson is right.

I looked into a check we added recently for 3).  It was added in NSS 3.12.7:
https://bugzilla.mozilla.org/show_bug.cgi?id=554354

Since you're using NSS 3.12.5.0, that makes 3) less likely, but still possible.

Ii suggest you use tcpdump or ssltap to get a trace of your own.

Yes.  To track this down, we need the server's certificate chain and the
"Server Key Exchange" handshake message, if it is used.

Wan-Teh


--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699

bernhard.thalm...@painstakingminds.com - Solution Architect

This e-mail may contain confidential and/or privileged information.If you are not the intended recipient (or have received this email in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to