Bug 521111 - "select a server to authenticate" dialog empty
"select a server to authenticate" dialog empty
Status: CLOSED NOTABUG
Product: 389
Classification: Community
Component: Directory Console (Show other bugs)
7.1
All Linux
low Severity medium
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On:
Blocks: 434915 389_1.3.0
  Show dependency treegraph
 
Reported: 2009-09-03 13:44 EDT by Michael Breuer
Modified: 2015-01-04 18:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-07 18:27:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
console log as requested (63.49 KB, text/plain)
2009-09-03 17:50 EDT, Michael Breuer
no flags Details

  None (edit)
Description Michael Breuer 2009-09-03 13:44:01 EDT
Description of problem:

After installation of keys, enabling of SSL and restart, the console gui asks, "select a server to authenticate" for both the DS and admin servers. This happens once. I select nothing (as that is the only option), say, "OK" and everything then seems to work.

The key was signed by cacert, if that matters... I did add the CA root key. I also note that I was asked whether to trust the key. 

Version-Release number of selected component (if applicable):
389-console-1.1.3-3.fc11.noarch


How reproducible:
Haven't tried... seems likely to be easy to reproduce.

Steps to Reproduce:
1. Install 389 admin, dirsrv and console
2. Install signed ssl keys from cacert.org
3. Enable ssl
4. restart
  
Actual results:

Clicking on either "administration server" or "directory server" yields a console dialog asking, "select a server to authenticate." The only option is blank. Clicking OK seems to result in correct operation.

Expected results:

A server instance should be displayed (I have only one instance).
Comment 1 Michael Breuer 2009-09-03 14:12:54 EDT
Update: the dialog reappears whenever the server (dirsrv or dirsrv-admin) is restarted.
Comment 2 Rich Megginson 2009-09-03 16:30:38 EDT
run 389-console -D 9 -f console.log
then attach console.log to this bug - be sure to obscure any sensitive information first
Comment 3 Michael Breuer 2009-09-03 17:50:19 EDT
Created attachment 359736 [details]
console log as requested

Two of the events - one at line 192, the second at line 896. In both cases, the drop down menu was empty.
Comment 4 Rich Megginson 2009-09-30 11:19:57 EDT
Are you using certificate based auth or username/password auth with the console?
Comment 5 Rich Megginson 2009-09-30 11:39:35 EDT
I've done lots and lots of console SSL configuration, and I have not seen this issue.  Can you provide more detailed steps about how to reproduce?  What is your platform?
rpm -qi 389-ds-base
rpm -qi 389-admin
What version of java are you using?
Comment 6 Michael Breuer 2009-09-30 14:46:14 EDT
username/password.

Java is: java-1.6.0-openjdk-1.6.0.0-29.b16.fc11.x86_64

Requested rpm info below.

rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.2                             Vendor: Fedora Project
Release     : 1.fc11                        Build Date: Tue 25 Aug 2009 04:07:37 PM EDT
Install Date: Wed 02 Sep 2009 04:56:04 PM EDT      Build Host: x86-5.fedora.phx.redhat.com
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.2-1.fc11.src.rpm
Size        : 5287485                          License: GPLv2 with exceptions
Signature   : RSA/SHA1, Wed 26 Aug 2009 07:56:53 AM EDT, Key ID 1dc5c758d22e77f2
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package includes
the LDAP server and command line utilities for server administration.


rpm -qi 389-admin
Name        : 389-admin                    Relocations: (not relocatable)
Version     : 1.1.8                             Vendor: Fedora Project
Release     : 4.fc11                        Build Date: Tue 25 Aug 2009 04:10:58 PM EDT
Install Date: Wed 02 Sep 2009 04:56:09 PM EDT      Build Host: x86-2.fedora.phx.redhat.com
Group       : System Environment/Daemons    Source RPM: 389-admin-1.1.8-4.fc11.src.rpm
Size        : 1152919                          License: GPLv2 and ASL 2.0
Signature   : RSA/SHA1, Wed 26 Aug 2009 08:06:17 AM EDT, Key ID 1dc5c758d22e77f2
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Administration Server (admin)
Description :
389 Administration Server is an HTTP agent that provides management features
for 389 Directory Server.  It provides some management web apps that can
be used through a web browser.  It provides the authentication, access control,
and CGI utilities used by the console.
Comment 8 Nathan Kinder 2011-03-07 15:20:03 EST
There is no such string as "Select a server to authenticate" in the Console code.  I believe that the message you encountered was "Select a certificate to authenticate:", which is used for client certificate authentication.  It seems to me like you were being prompted for the client certificate to use to authenticate, but you do not have a client certificate installed in Console's certificate database.

When you configured SSL for Admin Server and Directory Server, what options did you choose with regards to client certificate authentication?
Comment 9 Nathan Kinder 2011-03-07 18:07:34 EST
I ran some tests, and I found that you get the "select a certificate to authenticate" dialog if client cert auth is required or optional for Admin Server and you login to Console.  If you do not have a client cert in the Console certificate database, the selection list is empty.  Clicking on "OK" causes the connection to just use basic auth over an SSL encrypted connection.  This seems to be working as designed.
Comment 10 Nathan Kinder 2011-03-07 18:27:33 EST
I don't believe that this is a bug.  It looks to me like client certificate auth was set to "optional" for Admin Server on the reporters system.

There is a clue as to why the reporter is seeing the certificate selection dialog more than once, and that has to do with the FQDN not being used everywhere.  From the attached Console debug logging, we can see the first time the certificate selection dialog is displayed, the connection with Admin Server is being made using "localhost" as the hostname:

HttpsChannel::select(...) - SELECT CERTIFICATE
https://localhost:9830/[0:0] open> Ready
https://localhost:9830/[0:0] accept> https://localhost:9830/admin-serv/authenticate

The second time that the certificate selection dialog is displayed, the connection with Admin Server is being made using the FQDN (which has been obscured from the debug logging):

HttpsChannel::select(...) - SELECT CERTIFICATE
AbstractServerObject.StatusThread: waiting for change listeners to register
AbstractServerObject.StatusThread: waiting for change listeners to register
AbstractServerObject.StatusThread: waiting for change listeners to register
https://<obscured server fqdn>:9830/[1:0] open> Ready
https://<obscured server fqdn>:9830/[1:0] accept> https://<obscured server fqdn>:9830/admin-serv/tasks/operation/StatusPing

The Console is confused and thinks that it is talking with a new/different Admin Server since the hostname is different this second time (the hostname was fetched from o=NetscapeRoot).  Since Console thinks this is a different server, it prompts for the certificate to use for client auth again.

This is all working as designed.  One should use the FQDN everywhere when using SSL.  In addition, client certificate auth can be disabled for Admin Server if one does not plan to use it.  No certificate selection dialogs will be displayed ever this way.  Closing this as NOTABUG.

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