Fortunately for me, the issue has gone away of its own free will (I
added a note about that in the Request Tracker under #740). It turns out
the version of Windows 2000 in the test lab was very old, without even
the High Encryption Pack installed. So it did all kind of awkward
things, like using an export ciphersuite with a non-export certificate.
After installing some Win2k and Internet Explorer service packs, the
server stopped doing that. Now, the 0.9.7c works for me as well.

I'm afraid the system backup from before applying the patches has
already been overwritten, so I was unable to revert the server to the
old state and test from the new snapshots. 

Tal

-----Original Message-----
From: Richard Levitte via RT [mailto:[EMAIL PROTECTED] 
Sent: Saturday, November 29, 2003 11:45 AM
To: Tal Mozes
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #740] SSL handshake broken after upgrading to
0.9.7c


The fix in X509_certificate_type() was correct but was built on old
data.  These days, export keys can be up to 1024 bits.  All of OpenSSL
0.9.7c, except for X509_certificate_type(), reflected these new rulings.
Another ticket (#771) pointed this out, and I changed
X509_certificate_type() yesterday to check if the key is up to 1024 bits
instead of 512, and if so, mark it as an export certificate.  That
change should resolve your issue as well.

Please try the latest 0.9.7 snapshot and see if your issue has gone
away.  If not, we need to dig deeper.

[EMAIL PROTECTED] - Tue Oct 21 17:19:56 2003]:

> After upgrading (from 0.9.7b) to 0.9.7c, SSL handshake fails. Here are

> the symptoms:
> SSL_connect breaks with SSL_R_MISSING_EXPORT_TMP_RSA_KEY. This happens

> because the client plans on using RSA_EXPORT1024_WITH_DES_CBC_SHA, and

> the server has a certificate with a 1024-bit RSA key.
> In 0.9.7b there was a bug in X509_certificate_type() that caused it to

> mark the server's public key with EVP_PKT_EXP (i.e. this is an export 
> cipher key). The bug was fixed in 0.9.7c, and so I have an EXPORT 
> cipher, with NON-EXPORT key.
> This causes a check in ssl3_check_cert_and_algorithm() to fail because

> an EXPORT algorithm is used with NON-EXPORT certificate, and no 
> temporary EXPORT key.
> My question is: Why is this check needed? Is it required in SSL/TLS 
> specification? It seems strange to me to blame the server for not 
> generating a temporary 512 bit key (the algorithm specifies explicitly

> RSA-1024...).
> Anybody encountered this before? Any solution / workaround?
> I'm using Windows 2000 Active Directory as the server, and the client
is
> my application which is linked with OpenLDAP and OpenSSL. It tries to 
> establish a LDAP over SSL connection on port 636. (Same client works 
> when linked with 0.9.7b) Thanks Tal
> 


--
Richard Levitte
[EMAIL PROTECTED]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to