Description of problem: When importing a CA certificate from the management console with trust flags enabled for server and client authentication, the flags are not saved. You must edit the trust and enable for the flags to be saved. See attached screenshots. ADS CA certificate used to import, also attached. Version-Release number of selected component (if applicable): 8.1 How reproducible: always Steps to Reproduce: 1. Install directory server 2. Connect to Directory Server console. 3. Select Manage Certificates 4. Enter a cert db password and confirm 5. Select CA Certs tab and install. 6. Browse to attached CA certificate. 7. Navigate wizard and verify trust flags are enabled. 8. Select the newly imported certificate and Edit Trust. Actual results: Trust flags are not enabled. Expected results: Trust flags to be enabled. Additional info: Editing and enabling the flags, does work.
Created attachment 330488 [details] adding cert screenshot
Created attachment 330489 [details] edit screenshot
Created attachment 330490 [details] ADS CA certificate
NOTE: Test environment was RHEL4 -64BIT and remote console on RHEL5 -32BIT This did not happen with Solaris and remote console on RHEL5 - 32BIT
I cannot reproduce with both console and server on rhel5 x86_64. I'm pretty sure the trust flags are parsed on the server side, not on the remote console side. In the cases that fail, what is the server side running?
Server side was RHEL4 -64BIT - and I did not see this with the other operating systems.
On the system that is failing - please verify the versions: rpm -qi redhat-ds-base rpm -qi redhat-ds-admin rpm -qi nss
I think this is a client side issue, and I think it has to do with the wrong version of idm-console-framework and jss being used. Please confirm that you are using idm-console-framework version 1.1.3 or later and jss version 4.2.5 or later.
-bash-3.00# rpm -qi idm-console-framework Name : idm-console-framework Relocations: (not relocatable) Version : 1.1.3 Vendor: Red Hat, Inc. Release : 8.el4idm Build Date: Wed 14 Jan 2009 01:32:27 PM PST Install Date: Thu 05 Feb 2009 09:47:08 AM PST Build Host: ls20-bc2-14.build.redhat.com Group : System Environment/Libraries Source RPM: idm-console-framework-1.1.3-8.el4idm.src.rpm Size : 1230137 License: LGPLv2 Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://directory.fedoraproject.org Summary : Identity Management Console Framework Description : A Java Management Console framework used for remote server management. -bash-3.00# rpm -qi jss Name : jss Relocations: (not relocatable) Version : 4.2.5 Vendor: Red Hat, Inc. Release : 1.el4idm Build Date: Thu 08 Jan 2009 04:44:20 PM PST Install Date: Thu 05 Feb 2009 09:47:03 AM PST Build Host: hs20-bc1-2.build.redhat.com Group : System Environment/Libraries Source RPM: jss-4.2.5-1.el4idm.src.rpm Size : 940970 License: MPL/GPL/LGPL Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.mozilla.org/projects/security/pki/jss/ Summary : Java Security Services (JSS) Description : Java Security Services (JSS) is a java native interface which provides a bridge for java-based applications to use native Network Security Services (NSS). This only works with gcj. Other JREs require that JCE providers be signed. The versions seem to be correct.
I still cannot reproduce this problem. If you can reproduce it, please run the console with -D 9 -f console.log and attach console.log to this bug.
Created attachment 331377 [details] console log
Here's the log - at this point sterope is not even installing the cert - it appears that it works but never installs. I've tried from two different remote consoles. the log is attached and what's odd is: http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> Admin-Server: RedHat-Administrator/8.0.4 HttpChannel.invoke: admin version = 8.0.4 The GUI shows the version as 8.1.0.
This looks like a different bug - the server should be returning RedHat-Administrator/8.1.0 - but that does not cause the cert problem. I tried to reproduce using rhel5 i386 as the console client and sterope as the server - it worked just fine - I was able to install a MS CA cert setting the trust flags, then edit them later, and it had the correct trust flag settings. However, I see this in the admin server error log on sterope: [Mon Feb 09 13:28:32 2009] [error] [client 10.16.2.64] *** glibc detected *** free(): invalid next size (fast): 0x000000000056d4a0 *** 13:28:32 corresponds to this request: http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] send> POST \ http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] send> /admin-serv/tasks/configuration/SecurityOp \ http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> HTTP/1.1 200 OK http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> Date: Mon, 09 Feb 2009 21:28:32 GMT http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> Server: Apache/2.0 HttpChannel.invoke: admin version = 2.0 http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> Admin-Server: Red Hat-Administrator/8.0.4 HttpChannel.invoke: admin version = 8.0.4 http://sterope.dsqa.sjc2.redhat.com:9830/[6:0] recv> Connection: close So there is definitely something fishy going on - looks like the program is crashing, but after writing the correct output - so there is no report of a problem in the console log
I restarted admin server on sterope - it's now reporting the correct version - RedHat-Administrator/8.1.0 - but that does not cause the cert problem. I guess we should note that in the docs - when you upgrade admin server, a restart is required to get the console log information to show the correct version of admin server - but this should not affect anything else.
Created attachment 331439 [details] diffs
Since you restarted the admin server, I am able to install the certificate with no problems from my remote console. I think we should change the title and re-assign the bug to deon for documenting that restart is required. okay?
Created attachment 331442 [details] cvs commit log Reviewed by: nkinder (Thanks!) Fix Description: In comment https://bugzilla.redhat.com/show_bug.cgi?id=483276#c13 there is a report of a memory error coming from the security CGI. While I could not reproduce this with the latest code, I did find a minor valgrind error with a buffer size. Platforms tested: RHEL5 Flag Day: no Doc impact: no
(In reply to comment #16) > Since you restarted the admin server, I am able to install the certificate with > no problems from my remote console. I think we should change the title and > re-assign the bug to deon for documenting that restart is required. okay? Ok.
fix verified DS 8.1 RHEL 4 -64bit and remote console RHEL 5 32bit
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html