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).
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.