[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iaik-ssl]cu|| BadCertificate-Message whith a particular SERVER-Certificate

For your information!

We are currently moving from  these  mailinglists newsgroups.
Please use news://news.iaik.at/jce.general for questions and
discussions regaring any of our toolkits.

These mailinglist will go out of service early 2003!
------------------------------------------------------------------ hello,

I have a PKCS#12 file containing a certificate and a private key, both 
containing a valid certchain with issuing- and rootCA.
To use the private key and the certificate in my Tomcat webserver (4.0
and/or 4.1), 
I have converted it with IAIK-JCE PKCS12 into a SUN JKS.  
Although the chain is in the right order ([0]->server, [1]->CA,
[2]->root-CA), none of my browsers is able to connect to this server. 

Depending on the browser and server version, I get different messages,
but mostly, the handshake process stops during or after
and tells my the following (the client certificate is NOT null!):
*** CertificateVerify
JsseJCE: Using JSSE internal implementation for cipher
HttpProcessor[8443][4], SEND SSL v3.0 ALERT:  fatal, description =
HttpProcessor[8443][4], WRITE:  SSL v3.0 Alert, length = 2
-------------------------------- /snip

My browser tells me the follwing at the same time (all translated from
Netsape 4.7: "The Server can not validate your certificate" 
IE 5.0 : -No popup- , only the page which tells me, that the 
server is not available Netscape 6.2: "Connection could not be 
established because of an unknown SSL handshake failiure -12271"
Sometimes, Netscape also told me that the signature of the server 
certificate is not valid.

Testing with an ISASILK-Client, the server send the following message:
*** CertificateVerify
JsseJCE: Using JSSE internal implementation for cipher
[read] MD5 and SHA1 hashes:  len = 134
0000: 0F 00 00 82 00 80 A0 7C   02 A3 E7 70 E9 55 88 E6 
0010: 5E B7 F6 0F 4E 0C 6C 95   62 05 37 72 29 02 1D 85 
0020: 1B CA AF C0 A8 91 0B 61   F1 50 81 9C 3F 07 D9 07 
0030: 49 4A F9 FC 15 21 4C AA   73 68 17 89 EC 2E 19 4D 
0040: 44 F0 85 BB 29 3C FD 45   34 31 C8 FA 87 B3 B8 D6 
0050: A4 72 59 04 00 74 1A D3   84 55 1D 81 F7 87 42 57 
0060: 8A 2C 2E 3E 03 03 07 53   57 82 D1 3E 37 EC 1A B6 
0070: 70 49 5F 34 2F A3 EF 97   DE 7C 0D B7 C5 33 3E AA 
0080: 51 FA BC 47 EA E4                                  Q..G..
HttpProcessor[8443][4], READ:  SSL v3.1 Change Cipher Spec, length = 1
JsseJCE: Using JSSE internal implementation for cipher
HttpProcessor[8443][4], READ:  SSL v3.1 Handshake, length = 40
Padded plaintext after DECRYPTION:  len = 40
0000: 17 E0 EB 51 16 89 E2 33   4C 82 2D D9 0A EE 05 7E 
0010: 42 77 9E 9C EB F0 8E 33   11 9C B2 04 10 BC 11 BE 
0020: 81 A7 AF 2E 5E 82 78 84                            ....^.x.
HttpProcessor[8443][4], SEND SSL v3.1 ALERT:  fatal, description =
HttpProcessor[8443][4], WRITE:  SSL v3.1 Alert, length = 2

-------------------------------- /snip

All these messages would'nt be surprising, if I would have used
certificates on the client side and the standard serverside truststore 
without my client CA certificate. 
- I'm using a Smartcard, issued by the same CA
- the serverside certificate requests contain the right issuers and 
  the client sends a certificate
- I also tried with the P12-File on the clientside and the converted 
  one on the serverside (Client and Server use the same cert). 
- *Surprise*: After changing the SERVER-KeyStore (and only this!), all
works fine!
- If I'm using the "server" certificate as PKCS#12 on the clientside,
and another
  server certificate, it also works.

Now I have the following questions: 
- Is there a connection between CertificateVerify and the
- Is it possible, that Browsers can't read certificates converted 
  from P12 with IAIK-JCE (-->an ecoding problem?)
- Another idea: Could the fact that the KeyUsage ( DigitalSignature, 
 Non_repudiation, Key_Encipherment) is set to "critical", interrupt 
 the handshake process? Do I need an extended key usage entry?
- Or is there a problem with certchains longer than two certificates?
  certificates it works with have a root-CA and no issuing CA

Has anybody encountered and solved a similar problem?



Alice Scheerer
Dipl. Informationswirtin
Fraunhofer - Institute for Secure Telecooperation (FhI-SIT)
Dolivostrasse 15
D-64293 Darmstadt (Germany)
Tel: +49-6151-869-60212 
e-mail: alice.scheerer@sit.fraunhofer.de

Mailinglist-archive at http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html

To unsubscribe send an email to listserv@iaik.at with the folowing content: UNSUBSCRIBE iaik-ssl