From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description of problem: When the administration server is configured to use the secure Directory Configuration server (the file adm.conf contains ldapurl: ldaps://ldap-model.polytechnique.fr:636/o=NetscapeRoot) the fds directory server console cannot show the certificate window when i click on the "Manage Certificates" button. The java exception is generated (tested on Windows console/Linux console with jre1.4, 1.5 and 1.6, httpd.worker on i386 and x86_64 architecture on CentOS5.1 with the latest patches). The "Manage Certificates" of the admin server console works fine. When i change the adm.conf to ldapurl: ldap://ldap-model.polytechnique.fr:389/o=NetscapeRoot everything works fine again (no java exception, the certificate window opens) The same configuration worked fine with fds1.0.4 console and server. Version-Release number of selected component (if applicable): fedora-ds-console-1.1.0-5.fc6 How reproducible: Always Steps to Reproduce: 1. Configure correctly the ldap server and admin server to use the secure connections (import CA in both bases, generate certificates for both ldap and admin server) 2. Change the configuration of the admin server in adm.conf (or by graphical console in "Configuration DS" tab) to ldaps://<hostname>:636 3. Open the part of the java console concerning the directory server itself 4. Click on the "Manage Certificates" button. Actual Results: Java exception and no certoficate wondow : JButtonFactory: button width = 144 JButtonFactory: button height = 19 Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at com.netscape.management.client.security.CertificateDialog.<init>(Unknown Source) at com.netscape.management.client.security.CertificateDialog.<init>(Unknown Source) at com.netscape.admin.dirserv.task.KeyCert.run(Unknown Source) at com.netscape.management.client.TaskModel.actionObjectRun(Unknown Source) at com.netscape.management.client.TaskPage$TaskList$ButtonMouseListener.mouseClicked(Unknown Source) at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Expected Results: No exception, window of certificate management appears Additional info: The logs : ==> /Logs/AdminServer/access <== 129.104.69.51 - cn=X LDAP Root [28/Jan/2008:15:36:49 +0100] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 - 129.104.69.51 - cn=X LDAP Root [28/Jan/2008:15:36:49 +0100] "POST /admin-serv/tasks/configuration/SecurityOp HTTP/1.0" 200 - ==> /Logs/AdminServer/error <== [Mon Jan 28 15:36:49 2008] [info] Connection to child 1 established (server ldap-model.polytechnique.fr:443, client 129.104.69.51) [Mon Jan 28 15:36:49 2008] [notice] [client 129.104.69.51] admserv_host_ip_check: ap_get_remote_host could not resolve 129.104.69.51 [Mon Jan 28 15:36:49 2008] [info] Initial (No.1) HTTPS request received for child 1 (server ldap-model.polytechnique.fr:443) [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(2651): [client 129.104.69.51] checking user cache for: cn=X LDAP Root [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(2654): [client 129.104.69.51] user found in cache cn=X LDAP Root [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1554): [client 129.104.69.51] admserv_check_authz: request for uri [/admin-serv/tasks/configuration/SecurityOp] [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1051): [client 129.104.69.51] check_auth_tasks_cache: task entry [cn=securityop,cn=configuration,cn=tasks,cn=admin-serv-ldap-model,cn=fedora administration server,cn=server group,cn=ldap-model.polytechnique.fr,ou=polytechnique.fr,o=netscaperoot] not cached [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1775): [client 129.104.69.51] admserv_check_authz: uri [tasks/configuration/SecurityOp] did not begin with [commands/] - not a command [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1828): [client 129.104.69.51] admserv_check_authz: execute CGI [/usr/lib/dirsrv/cgi-bin/security] args [(null)] [Mon Jan 28 15:36:49 2008] [info] Connection to child 1 closed (server ldap-model.polytechnique.fr:443, client 129.104.69.51) [Mon Jan 28 15:36:49 2008] [info] Connection to child 2 established (server ldap-model.polytechnique.fr:443, client 129.104.69.51) [Mon Jan 28 15:36:49 2008] [notice] [client 129.104.69.51] admserv_host_ip_check: ap_get_remote_host could not resolve 129.104.69.51 [Mon Jan 28 15:36:49 2008] [info] Initial (No.1) HTTPS request received for child 2 (server ldap-model.polytechnique.fr:443) [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(2651): [client 129.104.69.51] checking user cache for: cn=X LDAP Root [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(2654): [client 129.104.69.51] user found in cache cn=X LDAP Root [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1554): [client 129.104.69.51] admserv_check_authz: request for uri [/admin-serv/tasks/configuration/SecurityOp] [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1775): [client 129.104.69.51] admserv_check_authz: uri [tasks/configuration/SecurityOp] did not begin with [commands/] - not a command [Mon Jan 28 15:36:49 2008] [debug] mod_admserv.c(1828): [client 129.104.69.51] admserv_check_authz: execute CGI [/usr/lib/dirsrv/cgi-bin/security] args [(null)] [Mon Jan 28 15:36:49 2008] [info] Connection to child 2 closed (server ldap-model.polytechnique.fr:443, client 129.104.69.51) ==> /Logs/Ldap/access <== [28/Jan/2008:15:36:48 +0100] conn=117 fd=134 slot=134 SSL connection from 129.104.69.50 to 129.104.69.50 [28/Jan/2008:15:36:48 +0100] conn=117 SSL 128-bit RC4 [28/Jan/2008:15:36:48 +0100] conn=117 op=0 BIND dn="cn=X LDAP Root" method=128 version=3 [28/Jan/2008:15:36:48 +0100] conn=117 op=0 RESULT err=0 tag=97 nentries=0 etime=0.003000 dn="cn=x ldap root" [28/Jan/2008:15:36:48 +0100] conn=117 op=1 SRCH base="cn=admin-serv-ldap-model, cn=Fedora Administration Server, cn=Server Group, cn=ldap-model.polytechnique.fr, ou=polytechnique.fr, o=NetscapeRoot" scope=2 filter="(nsExecRef=*)" attrs="nsExecRef nsLogSuppress" [28/Jan/2008:15:36:48 +0100] conn=117 op=1 RESULT err=0 tag=101 nentries=23 etime=0.003000 [28/Jan/2008:15:36:48 +0100] conn=117 op=2 UNBIND [28/Jan/2008:15:36:48 +0100] conn=117 op=2 fd=134 closed - U1 [28/Jan/2008:15:36:48 +0100] conn=118 fd=135 slot=135 SSL connection from 129.104.69.50 to 129.104.69.50 [28/Jan/2008:15:36:48 +0100] conn=118 op=-1 fd=135 closed - Encountered end of file. [28/Jan/2008:15:36:48 +0100] conn=119 fd=134 slot=134 SSL connection from 129.104.69.50 to 129.104.69.50 [28/Jan/2008:15:36:48 +0100] conn=119 op=-1 fd=134 closed - Encountered end of file. console.log : cf attached file
Created attachment 293158 [details] The logfile of "fedora-idm-console -D 9 2>&1 |tee console.log"
Same here when I check "Use SSL in Console" under encryption in the directory server config.
What appears to be going on is that in 1.1, the code was changed to get the security dir from the directory server, from the cn=config entry. If the Use SSL in Console is checked, it attempts to use LDAPS to read this entry. However, the CGI code is not properly initializing NSS, so this fails. But even if this is fixed, it will still fail, unless the CA certificate has been installed in the Admin Server's key/cert database (/etc/dirsrv/admin-serv). The reason why it worked in the old code is that it just assumed the key/cert database was under /opt/fedora-ds/alias. In 1.1, each server has its own private key/cert db directory, which defaults to /etc/dirsrv/slapd-instance, but may be different depending on the security needs of the user.
> But even if this is fixed, it will still fail, unless the CA certificate has > been installed in the Admin Server's key/cert database (/etc/dirsrv/admin-serv). I think that this point is not a real problem - anyway the CA certificate SHOULD be installed in the admin server's key/cert store (/etc/dirsrv/admin-serv).
fedora-ds-admin-1.1.6-1.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/fedora-ds-admin-1.1.6-1.fc8
fedora-ds-admin-1.1.6-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/fedora-ds-admin-1.1.6-1.fc9
fedora-ds-admin-1.1.6-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
fedora-ds-admin-1.1.6-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
*** This bug has been marked as a duplicate of bug 442103 ***