Bug 483276 - Certificate Management: Adding Trusted CA from Console, does not save the trust flags
Summary: Certificate Management: Adding Trusted CA from Console, does not save the tr...
Alias: None
Product: Red Hat Directory Server
Classification: Red Hat
Component: Directory Console
Version: 8.1
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
Reported: 2009-01-30 17:00 UTC by Jenny Severance
Modified: 2015-01-04 23:36 UTC (History)
2 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-29 23:10:06 UTC
Target Upstream Version:

Attachments (Terms of Use)
adding cert screenshot (90.90 KB, image/png)
2009-01-30 17:01 UTC, Jenny Severance
no flags Details
edit screenshot (93.72 KB, image/png)
2009-01-30 17:02 UTC, Jenny Severance
no flags Details
ADS CA certificate (1.67 KB, application/octet-stream)
2009-01-30 17:02 UTC, Jenny Severance
no flags Details
console log (157.81 KB, text/plain)
2009-02-09 21:37 UTC, Jenny Severance
no flags Details
diffs (1007 bytes, patch)
2009-02-10 17:36 UTC, Rich Megginson
no flags Details | Diff
cvs commit log (175 bytes, text/plain)
2009-02-10 17:50 UTC, Rich Megginson
no flags Details

Description Jenny Severance 2009-01-30 17:00:32 UTC
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):

How reproducible:

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.

Comment 1 Jenny Severance 2009-01-30 17:01:11 UTC
Created attachment 330488 [details]
adding cert screenshot

Comment 2 Jenny Severance 2009-01-30 17:02:05 UTC
Created attachment 330489 [details]
edit screenshot

Comment 3 Jenny Severance 2009-01-30 17:02:25 UTC
Created attachment 330490 [details]
ADS CA certificate

Comment 4 Jenny Severance 2009-01-30 18:46:59 UTC
NOTE:  Test environment was RHEL4 -64BIT and remote console on RHEL5 -32BIT
This did not happen with Solaris and remote console on RHEL5 - 32BIT

Comment 5 Rich Megginson 2009-02-04 21:15:37 UTC
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?

Comment 6 Jenny Severance 2009-02-04 21:22:51 UTC
Server side was RHEL4 -64BIT - and I did not see this with the other operating systems.

Comment 7 Rich Megginson 2009-02-04 21:39:11 UTC
On the system that is failing - please verify the versions:
rpm -qi redhat-ds-base
rpm -qi redhat-ds-admin
rpm -qi nss

Comment 8 Rich Megginson 2009-02-05 16:07:16 UTC
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.

Comment 9 Jenny Severance 2009-02-05 18:40:31 UTC
-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.

Comment 10 Rich Megginson 2009-02-09 20:20:20 UTC
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.

Comment 11 Jenny Severance 2009-02-09 21:37:20 UTC
Created attachment 331377 [details]
console log

Comment 12 Jenny Severance 2009-02-09 21:37:34 UTC
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.

Comment 13 Rich Megginson 2009-02-10 00:30:30 UTC
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] *** 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

Comment 14 Rich Megginson 2009-02-10 00:49:44 UTC
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.

Comment 15 Rich Megginson 2009-02-10 17:36:50 UTC
Created attachment 331439 [details]

Comment 16 Jenny Severance 2009-02-10 17:47:40 UTC
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?

Comment 17 Rich Megginson 2009-02-10 17:50:14 UTC
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

Comment 18 Rich Megginson 2009-02-10 18:17:36 UTC
(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?


Comment 19 Jenny Severance 2009-03-18 16:38:18 UTC
fix verified DS 8.1 RHEL 4 -64bit and remote console RHEL 5 32bit

Comment 20 Chandrasekar Kannan 2009-04-29 23:10:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.