Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Problem with Novell CLDAP communicate with Oracle OID via SSL

Problem with Novell CLDAP communicate with Oracle OID via SSL

From: Arthur Chang <thebluesheep_at_yahoo.com>
Date: 2 Feb 2005 17:01:25 -0800
Message-ID: <1107392234.831183.68870@l41g2000cwc.googlegroups.com>


Hi,

During phase 1 of our LDAP implementation, we have successfully used Novell's C LDAP SDK and OpenVMS's native LDAP SDK to communicate with OID (10g). Now for the phase 2 of implementation, we want to setup the communication to go through SSL. During our initial research, we are unable to use Novell's SDK talk to OID in SSL mode (haven't tried OpenVMS's SDK yet).

I setup OID Certificate Authority, and setup the OID Server wallet with certificate issued by the OCA. I can then successfully use the following applications communicate with OID via SSL (Server Authentication only):

  1. ORACLE Directory Manager (client wallet contains root CA's certificate)
  2. ORACLE's ldapsearch (with -W "file:c:\oid_wallet" -U 2)
  3. Using JXplorer (http://pegacat.com/jxplorer/), import CA's certificate

However, when I tried with Novell's LDAPSEARCH, it displays the following error:

C:\>ldapsearch -h voodoo -e "c:\\ldap\\openssl\\ocarootcert.der" -p 636
-v (cn=orcladmin)

ldapssl_client_init ( c:\\ldap\\openssl\\ocarootcert.der, NULL ) ldapssl_init ( voodoo, 636, 1 )
ldap_bind: Can't contact LDAP server

The "Can't contact LDAP server" is response code 81. I also tried to create my own program using Novell's API, and got the same result as well.

SSLDUMP shows the following:

C:\ldap\ssldump\out32>ssldump -Ad -i
"\Device\Packet_{EDE0916E-739F-4AED-B97D-6D3F41A0C111}" New TCP connection #1: xxxxx.xxxxx.xxxxxx.xxx(3583) <-> voodoo.xxxxx.xxx.xxx(636)
1 1 0.0416 (0.0416) C>S SSLv2 compatible client hello Version 3.0
cipher suites

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL2_CK_3DES
SSL_DHE_DSS_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL2_CK_RC2
SSL2_CK_RC4
SSL2_CK_RC464
SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL2_CK_DES
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5

SSL2_CK_RC2_EXPORT40
SSL2_CK_RC4_EXPORT40
1 2 0.0425 (0.0008) S>CV3.0(58) Handshake ServerHello
Version 3.0
random[32]=
42 01 6e ac 3c 09 69 26 a7 82 55 f5 ee f8 58 fa 5c 35 3e 0c 79 26 2e 4d 09 4d ee 47 32 32 53 4e session_id[16]=
72 b1 9d d4 47 fb 75 e6 38 e4 8f 5d a8 a6 09 6e
cipherSuite         SSL_RSA_WITH_3DES_EDE_CBC_SHA
compressionMethod                   NULL
1 3 0.0430 (0.0005) S>CV3.0(1961) Handshake Certificate
certificate[1044]=
30 82 04 10 30 82 02 f8 a0 03 02 01 02 02 01 06 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 30 71 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 1b 30 19 06 03 55 04 0a 13 12 43 65 72 6e 65 72 20

.......(skip).......

1 4 0.0431 (0.0000) S>CV3.0(4) Handshake ServerHelloDone
1 5 0.0453 (0.0021) C>SV3.0(132) Handshake ClientKeyExchange
EncryptedPreMasterSecret[128]=
b6 eb 0c 3d d8 e1 c9 e2 27 e8 b5 62 81 68 ba df 5f 06 32 ba d7 e0 8b 52 ce 3a 8c 07 bb 4d b2 f1 a7 d2 1d 12 0c d3 d8 73 9c b9 c2 e4 d4 7d 8a 6c da 22 f3 de 50 e3 e7 67 7c 4a 5d c5 78 74 f9 d5 00 41 34 3e 79 80 03 47 61 f2 26 4a 2a 94 75 f8 44 38 b4 b5 f7 0c 33 7c 56 48 1b ae a6 09 ab 4d 0f d4 3b b5 d0 58 59 97 86 34 f5 58 4b d8 86 c2 af 51 45 ca 33 a0 5a 4a a6 64 1d 5f 75 ac 80 5c

1 6  0.0453 (0.0000)  C>SV3.0(1)  ChangeCipherSpec
1 7  0.0453 (0.0000)  C>SV3.0(64)  Handshake
1 8  0.0911 (0.0457)  S>CV3.0(1)  ChangeCipherSpec
1 9  0.0911 (0.0000)  S>CV3.0(64)  Handshake
1 10 0.0914 (0.0002)  C>SV3.0(24)  application_data
1 11 0.0914 (0.0000)  C>SV3.0(40)  application_data
1 12 0.0965 (0.0050)  S>CV3.0(24)  Alert
1 13 0.0965 (0.0000)  S>CV3.0(24)  Alert
1    0.0966 (0.0000)  S>C  TCP RST

Looks like all the handshake steps have been completed, but when the client tried to send the data, OID Server rejected and then aborted the communication on line "1 12" and "1 13".

Conclusion:
Based on our testing, it looks like we have setup OID correctly, because both ODM and JXplorer can communicate with it via SSL (Server Authentication Only). Why is it failing for Novell's LDAP SDK? Is there other special configuration we need to make? Any comment or suggestion will be great.

Thanks.
-Arthur Chang
Received on Wed Feb 02 2005 - 19:01:25 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US