Description of problem:
Running 389-console-1.1.7-1.fc15 and connecting to 389 server on EL5. I connected to the directory server and through manage certificates imported 3 CA certificates. However, they went into the /etc/dirsrv/admin-serv database instead of the /etc/dirsrv/slapd-cora database.
No 1.1.7 version in list, so chose 1.1.3 instead.
On the server:
Was able to reproduce on f15 - using the directory server manage certificates ui, the cert is installed in the admin server cert db.
Turns out that even though NSS_InitContext works for TLS/SSL, it doesn't really work for key/cert db management. I'm afraid the only way to really get this to work properly is for security.c to do a full, complete, and total NSS shutdown, which means we need to find a way to pass that all the way through to the LDAP layer to make it release any NSS resources used doing LDAPS/startTLS.
Created attachment 530746 [details]
65e4166..f2e6124 master -> master
Author: Rich Megginson <email@example.com>
Date: Fri Oct 28 15:33:06 2011 -0600
Reviewed by: nhosoi (Thanks!)
Fix Description: Now that the openldap/NSS memory leaks have been fixed, we
do not need the workaround of using NSS_InitContext, which doesn't work
anyway for cert db management. The fix is to revert to the old behavior
of using NSS_Shutdown/NSS_Initialize so that we can be sure we are using
the correct NSS database.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
*** Bug 750408 has been marked as a duplicate of this bug. ***
Installed CA cert from DS console and It is listed under :
[root@snmaptest ~]# cd /etc/dirsrv/slapd-snmaptest
[root@snmaptest slapd-snmaptest]# certutil -L -d .
Certificate Nickname Trust Attributes
Example Certificate Authority CT,,
CA cert CT,,
(In reply to comment #8)
> Status update?
Fixed in 389-admin-1.1.25 in updates-testing
Confirmed!! Worked after updating to 389-admin-1.1.25 in updates-testing