Bug 521111

Update: the dialog reappears whenever the server (dirsrv or dirsrv-admin) is restarted.

run 389-console -D 9 -f console.log
then attach console.log to this bug - be sure to obscure any sensitive information first

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.

Are you using certificate based auth or username/password auth with the console?

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?

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.

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?

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.

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.