Re: LDAP errors - certificates

[Jakub Talaš]

All certificates in iManager - Novell Certificate access - Server
certificates have Valid status.
CA is also valid.

I managed to export self-signed certificate of CA and used it to work with
ldap search program and it worked. But it didn't work with Server
certificate.

magic31 wrote:

>
> jtalas;2016850 Wrote:
>> ...:sslv3 alert bad certificate - SSL alert number 42
> Not sure what the issue is... but that clearly indicates an error with
> the certificate itself.
>
> Have you verified the CA is in working order and is also still valid?
>
> Maybe try repairing the server's certificates using iManager, and then
> rerun the namconfig -k followed by a namconfig cache_refresh.
>
> -Willem
>
>

[Edward van der Maas]

Jakub Talaš wrote:

> I have discovered that servercert.pem in /etc/ssl/servercerts is
> signed by FQDN of server. (in Konqueror's builtin viewer)
> On testing installation (but on OES2SP1, productive server is OES2
> only) is servercert.pem signed by its FQDN as well as CA. Could this
> be the problem?

A cert can't be signed by two parties. You probably see the FQDN of
your server which is the subject and the issuer (sign) is the CA of
your tree.

To add to Willem, LUM will need to trust the certificate of your LDAP
server. This is done by importing the trusted root certificate of the
CA of your tree. I'm not sure though where this should be stored though
for LUM to use it.

--
Cheers,
Edward

[Jakub Talaš]

I have discovered that servercert.pem in /etc/ssl/servercerts is signed by
FQDN of server. (in Konqueror's builtin viewer)
On testing installation (but on OES2SP1, productive server is OES2 only) is
servercert.pem signed by its FQDN as well as CA. Could this be the problem?

[Jakub Talaš]

LDAP Search works for me well in anonymous mode.

Peter Kuo wrote:

> Jakub Talaš wrote:
>
>> Treating simple bind with empty DN and no password as anonymous
>
> You don't have anonymous bind disabled by any chance?
>

[Jakub Talaš]

Hi, I can't connect to LDAP using SSL. Trace says:

TLS accept failure 1 on connection 0xcf2d480, setting err = -5875. Error
stack:
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad

certificate - SSL alert number 42

and namconfig cannot connect to ldap server:
/usr/sbin/namcd[9115]: deinitialized the worker threads
/usr/sbin/namcd[9115]: deinitialized the cache refresh thread
/usr/sbin/namcd[9115]: monitorChangesInLDAP: ldap_result: Can't contact LDAP
server
/usr/sbin/namcd[9115]: deinitialized the LDAP watcher thread
/usr/sbin/namcd[9115]: Deleted hash tables and flushed data into local files
/usr/sbin/namcd[9115]: Deinitialized threads
namcd: SIGTTOU caught
namcd: SIGTTIN caught
namcd: SIGTSTP caught
/usr/sbin/namcd[23750]: Starting namcd..
/usr/sbin/namcd[23750]: namcd populating the user hash tables
/usr/sbin/namcd[23750]: namcd populating group hash tables
/usr/sbin/namcd[23750]: namcd Populated hash tables
/usr/sbin/namcd[23750]: Created all the threads

When I run namconfig -k everything succeeded, but it didn't help.
Certificates in /var/lib/novell-lum as well as in /etc/ssl/servercerts are
not invalid.

in iManager, I use SSL CertificateDNS to use with LDAP.

[Jakub Talaš]

Yes, I did. But still the same.

Edward van der Maas wrote:

> Jakub Talaš wrote:
>
>> Although, namcd says, that it can't contact ldap server, tracing ldap
>> events shows these lines when "rcnamcd restart"
>>
>> New TLS connection 0xc9c86c0 from 172.16.0.31:38098, monitor =
>> 0xee516ba0, index = 1
>> Monitor 0xee516ba0 initiating TLS handshake on connection 0xc9c86c0
>> DoTLSHandshake on connection 0xc9c86c0
>> BIO ctrl called with unknown cmd 7
>> Completed TLS handshake on connection 0xc9c86c0
>> DoBind on connection 0xc9c86c0

>> Treating simple bind with empty DN and no password as anonymous

>> Bind name:NULL, version:3, authentication:simple
>> Sending operation result 0:"":"" to connection 0xc9c86c0
>> DoSearch on connection 0xc9c86c0
>> Search request:
>> base: "o=mou"
>> scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
>> filter: "(objectclass=uamPosixGroup)"
>> attribute: "1.1"
>> Server: oes2
>> NDSTrace:
>>
>
> Hmm...not sure. Have you tried a simple reconfigure from yast for lum ?
>
>
>

[Jakub Talaš]

Server's local IP address is 31.

oes2:~ # ll /var/lib/novell-lum/
....
-rw-r--r-- 1 root root 834 2010-09-01 21:23 .172.16.0.12.der
-rw-r--r-- 1 root root 1316 2010-09-01 21:27 .172.16.0.31.der

oes2:~ # namconfig get
base-name=o=mou
user-context=
group-context=
admin-fdn=cn=unis,o=mou
proxy-user-fdn=
proxy-user-pwd=
alternative-ldap-server-list=172.16.0.12
preferred-server=172.16.0.31
num-threads=5 [default: '5']
schema=rfc2307
enable-persistent-cache=yes
user-hash-size=211 [default: '211']
group-hash-size=211 [default: '211']
persistent-cache-refresh-period=28800 [default: '28800']
persistent-cache-refresh-flag=all
create-home=yes
enable-boma=no
type-of-authentication=2 [default: '1']
certificate-file-type=der
ldap-ssl-port=636 [default: '636']
ldap-port=389 [default: '389']
support-alias-name=no
support-outside-base-context=yes
cache-only=no
persistent-search=yes
case-sensitive=no

oes2:~ # cat /etc/sysconfig/novell/ldap_servers/172.16.0.31
CONFIG_LDAP_SERVER_IP="172.16.0.31"
CONFIG_LDAP_PORT="389"
CONFIG_LDAP_SECURE_PORT="636"

NAMCD restart:
Sep 1 21:27:23 oes2 /usr/sbin/namcd[20855]: Starting namcd..
Sep 1 21:27:23 oes2 /usr/sbin/namcd[20855]: namcd populating the user hash
tables
Sep 1 21:27:23 oes2 /usr/sbin/namcd[20855]: namcd populating group hash
tables
Sep 1 21:27:23 oes2 /usr/sbin/namcd[20855]: namcd Populated hash tables
Sep 1 21:27:23 oes2 /usr/sbin/namcd[20855]: Created all the threads
Sep 1 21:27:39 oes2 /usr/sbin/namcd[20855]: deinitialized the worker
threads
Sep 1 21:27:39 oes2 /usr/sbin/namcd[20855]: deinitialized the cache refresh
thread
Sep 1 21:27:39 oes2 /usr/sbin/namcd[20855]: monitorChangesInLDAP:

ldap_result: Can't contact LDAP server

Sep 1 21:27:42 oes2 /usr/sbin/namcd[20855]: deinitialized the LDAP watcher
thread
Sep 1 21:27:45 oes2 /usr/sbin/namcd[20855]: Deleted hash tables and flushed
data into local files
Sep 1 21:27:45 oes2 /usr/sbin/namcd[20855]: Deinitialized threads
Sep 1 21:27:46 oes2 namcd: SIGTTOU caught
Sep 1 21:27:46 oes2 namcd: SIGTTIN caught
Sep 1 21:27:46 oes2 namcd: SIGTSTP caught
Sep 1 21:27:46 oes2 /usr/sbin/namcd[20976]: Starting namcd..
Sep 1 21:27:46 oes2 /usr/sbin/namcd[20976]: namcd populating the user hash
tables
Sep 1 21:27:46 oes2 /usr/sbin/namcd[20976]: namcd populating group hash
tables
Sep 1 21:27:46 oes2 /usr/sbin/namcd[20976]: namcd Populated hash tables

Jakub Talaš wrote:

> This should be in /var/lib/novell-lum. And there is correct certificate.

>
>
>
> Edward van der Maas wrote:
>

[Jakub Talaš]

Although, namcd says, that it can't contact ldap server, tracing ldap events
shows these lines when "rcnamcd restart"

New TLS connection 0xc9c86c0 from 172.16.0.31:38098, monitor = 0xee516ba0,
index = 1
Monitor 0xee516ba0 initiating TLS handshake on connection 0xc9c86c0
DoTLSHandshake on connection 0xc9c86c0
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0xc9c86c0
DoBind on connection 0xc9c86c0
Treating simple bind with empty DN and no password as anonymous
Bind name:NULL, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0xc9c86c0
DoSearch on connection 0xc9c86c0
Search request:
base: "o=mou"
scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(objectclass=uamPosixGroup)"
attribute: "1.1"
Server: oes2
NDSTrace:

[Jakub Talaš]

This should be in /var/lib/novell-lum. And there is correct certificate.

Edward van der Maas wrote:

[Jakub Talaš]

magic31 wrote:

>
> jtalas;2016876 Wrote:
>> I managed to export self-signed certificate of CA and used it to work
>> with
>> ldap search program and it worked. But it didn't work with Server
>> certificate.

> As a check, how is the eDirectory LDAP server object configured for
> that server? Is it pointing to the correct certificate object?

Yes it is correct.

> jtalas;2016876 Wrote:
>> I have discovered that servercert.pem in /etc/ssl/servercerts is signed
>> by
>> FQDN of server. (in Konqueror's builtin viewer)
>> On testing installation (but on OES2SP1, productive server is OES2
>> only) is
>> servercert.pem signed by its FQDN as well as CA. Could this be the
>> problem?

> Not 100% usre on that one, but it's not relevant for OES2 - those
> certificates are the ones created by YAST during SLES/OES install... if
> you have configured the server to use the eDirectory certificates while
> doing the OES configuration, this is disguarded (which is the default
> configuration).
>
> Have you checked using YaST > OES Install and Configuration if the LDAP
> and LUM configured ip's are valid?
>

I did it now, there was an address pointing to another server, I deleted it
but it didnt help.

[Edward van der Maas]

Jakub Talaš wrote:

> Although, namcd says, that it can't contact ldap server, tracing ldap
> events shows these lines when "rcnamcd restart"
>
> New TLS connection 0xc9c86c0 from 172.16.0.31:38098, monitor =
> 0xee516ba0, index = 1
> Monitor 0xee516ba0 initiating TLS handshake on connection 0xc9c86c0
> DoTLSHandshake on connection 0xc9c86c0
> BIO ctrl called with unknown cmd 7
> Completed TLS handshake on connection 0xc9c86c0
> DoBind on connection 0xc9c86c0
> Treating simple bind with empty DN and no password as anonymous
> Bind name:NULL, version:3, authentication:simple
> Sending operation result 0:"":"" to connection 0xc9c86c0
> DoSearch on connection 0xc9c86c0
> Search request:
> base: "o=mou"
> scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
> filter: "(objectclass=uamPosixGroup)"
> attribute: "1.1"
> Server: oes2
> NDSTrace:
>

Hmm...not sure. Have you tried a simple reconfigure from yast for lum ?

--
Cheers,
Edward

[Peter Kuo]

Jakub Talaš wrote:

> Treating simple bind with empty DN and no password as anonymous

You don't have anonymous bind disabled by any chance?

--

Peter
eDirectory Rules!
http://www.DreamLAN.com