on 2007 May 07 5:34 PM
Hi,
we are trying to connect our portal server (2004s) to the corporate LDAP-Server (Novell) via SSL in read only mode.
Unfortunately due to our IT infrastructure the portal server can't see the LDAP-server directly. There is a router inbetween the two which translates the IP-address and the port of the LDAP server.
We entered all information the way the portal server sees the LDAP server (including a valid dialogue user) and we can ping to the LDAP server from the UNIX-machine the portal is running on. Connection tests from the portal's UI fail.
The problem seems to be that the portal server rejects the certificate of the LDAP-server. We found "Peer certificate is not trusted or expired" messages in the defaultTrace files.
Am I right in assuming that the handshake is meant to go as follows:
1. First the LDAP server sends its certificate
2. The portal server authenticates it.
3. The portal server sends user name and password.
If that is the case, how can we make the portal server accept the certificate from the LDAP server even though the portal only sees the router? We already imported the certificate of the LDAP-server to the portal's key store, but the way I see it the problem is the router inbetween the two.
Unfortunately, getting rid of the router is not an option.
Thanks a lot in advance,
Jens
Addendum:
The LDAP server logs contain the following:
[07.05.2007 16:13:02.71] LDAP : New TLS connection 0xb78c110 from 10.64.6.244:56405, monitor = 0xb9c, index = 11
[07.05.2007 16:13:02.85] LDAP : Monitor 0xb9c initiating TLS handshake on connection 0xb78c110
[07.05.2007 16:13:02.85] LDAP : DoTLSHandshake on connection 0xb78c110
[07.05.2007 16:13:02.96] LDAP : TLS accept failure 1 on connection 0xb78c110, setting err = -5875. Error stack:
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate - SSL alert number 42
[07.05.2007 16:13:02.96] LDAP : TLS handshake failed on connection 0xb78c110, err = -5875
[07.05.2007 16:13:02.96] LDAP : BIO ctrl called with unknown cmd 7
[07.05.2007 16:13:02.98] LDAP : Server closing connection 0xb78c110, socket error = -5875
[07.05.2007 16:13:02.98] LDAP : Connection 0xb78c110 closed
Solved:
1. received LDAP-cert., intermediate CA and root CA from corporate certification dept.
2. visual admin: Imported all three certificates to "Trusted CAs"
3. visual admin: Exported private key of portal and re-imported it appending certificate chain (private key + intermediate CA + root CA).
4. set portal datasource to "novell_readonly_db".
5. restarted portal server
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jens,
We r facing the same problem on nw2004s with Novell for SSL.Can you please share your inputs,that how did you resolved the problem.
Thanks
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Amit,
I'm sorry for the delay.
In answer to your question, unfortunately the portal-LDAP-connection is on hold for the time being.
But we were in contact with SAP as well as the people responsible for the SSL certificates, so I can give you some further input:
The bottom line was that the Java keystore does not support certificates with a key bigger than 1024 Bits. They can be imported and everything seems allright. But the portal can't extract them from the keystore afterwards. That was our first problem.
Our second problem was that the certificate chain had gaps. So the certification department of our company issued completely new tickets that are supposed to provide a complete authentication chain and have 1024 bits.
Unfortunately I can't tell you if this solved the problem - at least "not yet".
Bye,
Jens
Do you have port 636 open on the router going both ways?
LDAP should be a four way handshake:
The Client sends a hello message with a certificate request.
The Sever sends a hello back with communications preferences and its certificate.
Client and server negotiate username password and cert with each other.
Information is now exchanged encrypted and with the negotiated preferences.
Hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
David,
thanks for your answer.
The router translates the port from 636 to 5001. But this really should not be the issue since it's just a translation and both sides should still be able to communicate. (The portal is set to use port 5001.)
I'm wondering how the portal server can recognize a certificate from an issuing server it doesn't even see (since the router changes the IP).
From the looks of it in our case both sides seem to be able to communicate, but somehow the authentication doesn't work. Both sides claim to have problems with the certificate.
Thanks and bye,
Jens
I'm a bit confused now and I'm not sure if we are talking about the same thing:
Are you saying that the portal must communicate with the LDAP server over two different ports? I was under the impression that the LDAP server sends its certificate over the same port the LDAP data is transferred over aftewards.
Our infrastructure looks like this:
LDAP SSL 636 <-> 636 Router 5001 <-> 5001 Portal
I configured the UME to use port 5001 for LDAP (SSL).
The HTTP and HTTPS ports the portal server is reached by are in the fiffty thousand range (e.g. 54100 for HTTP) and of course don't match the LDAP port we use.
Thanks,
Jens
It's a Novell Meta Directory Server.
At the moment we are investigating the possibility to let the router forward the LDAP server's name. Maybe then the problem with the certificate will be solved.
I suspect the portal server rejects the certificate because it doesn't see the LDAP server under its name. We are currently using the IP address.
We now have further input. I wasn't aware that trying to connecting a Novell LDAP to the portal using SSL would turn out to be such a complex endeavor.
First of all the certificate from the LDAP server I got contains a key of 2048 Bit length, which - so I've been told - could be a problem in combination with the Java keystore of the portal. Can anyone confirm that? Is it true that only keys with a maximum lenth of 1024 bits should be used?
Apparently, being able to import a key into the keystore doesn't necessarily mean it can be read from the keystore. Does anyone know where the keystore on a UNIX portal installation is normally located? We'd like to check the keys in the keystore with the keytool (e.g. if they can be read).
Secondly it seems we also need to import the ticket from the signing instance in the portal so that the portal can trace the signature all the way back to the LDAP server.
Thanks,
Jens
User | Count |
---|---|
76 | |
10 | |
10 | |
10 | |
10 | |
9 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.