Bug 430499

Summary: "Manage Certificates" button in fedora-ds-console causes Exception
Product: [Retired] 389 Reporter: Andrey Ivanov <andrey.ivanov>
Component: Directory ConsoleAssignee: Rich Megginson <rmeggins>
Status: CLOSED DUPLICATE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: low    
Version: 1.1.0CC: benl, orion, sputhenp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-16 20:57:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 452721    
Attachments:
Description Flags
The logfile of "fedora-idm-console -D 9 2>&1 |tee console.log" none

Description Andrey Ivanov 2008-01-28 14:49:07 UTC
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

Comment 1 Andrey Ivanov 2008-01-28 14:50:51 UTC
Created attachment 293158 [details]
The logfile of  "fedora-idm-console -D 9 2>&1 |tee console.log"

Comment 2 Orion Poplawski 2008-02-25 22:51:09 UTC
Same here when I check "Use SSL in Console" under encryption in the directory
server config.


Comment 6 Rich Megginson 2008-07-08 22:05:23 UTC
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.

Comment 7 Andrey Ivanov 2008-07-09 07:20:28 UTC
> 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).

Comment 8 Fedora Update System 2008-09-04 19:47:10 UTC
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

Comment 9 Fedora Update System 2008-09-04 19:48:43 UTC
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

Comment 10 Fedora Update System 2008-09-11 16:56:02 UTC
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.

Comment 11 Fedora Update System 2008-09-11 17:15:55 UTC
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.

Comment 12 Rich Megginson 2008-09-16 20:57:54 UTC

*** This bug has been marked as a duplicate of bug 442103 ***