cancel
Showing results for 
Search instead for 
Did you mean: 

EP --> LDAP: "Peer certificate is not trusted or expired"

Former Member
0 Kudos
513

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

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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.

Former Member
0 Kudos

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

Former Member
0 Kudos

LDAPS should be going on 636. Your portal UME is sending it that way and your LDAP expects it. Your LDAPS communication and SSL for the portal (50001) should not ride on the same port, You will be having communication issues.

Former Member
0 Kudos

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

Former Member
0 Kudos

What is your LDAP on? Active Directory?

Former Member
0 Kudos

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.

Former Member
0 Kudos

Yes, the FQDN may make the difference.

Former Member
0 Kudos

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

Former Member
0 Kudos

I have never used anything stronger than 1024. If the encryption strength is different, then you will have an issue there.

Secondly, yes. The certificate chain must be complete on both ends or a security issue will get in the way.

Former Member
0 Kudos

We're looking into the possibility of either signing with a shorter key (1024 max) or getting access to the LDAP server without SSL. Either way I will post the progress here.

Thanks a lot so far,

Jens