Issue Details (XML | Word | Printable)

Key: GLASSFISH-17132
Type: Bug Bug
Status: Resolved Resolved
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: Tim Quinn
Reporter: psartini
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
glassfish

CLONE -Admin console not loading after enabling secure-admin

Created: 29/Jul/11 01:02 PM   Updated: 11/Nov/11 05:18 PM   Resolved: 11/Nov/11 05:18 PM
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: None

Time Tracking:
Original Estimate: 2 hours
Original Estimate - 2 hours
Remaining Estimate: 2 hours
Remaining Estimate - 2 hours
Time Spent: Not Specified
Time Spent - Not Specified

Environment:

Server: FreeBSD 8.2 x64
Client: Mac OS X 10.6.7


Tags:
Participants: psartini, ref and Tim Quinn


 Description  « Hide
  • Download and install Glassfish 3.1 final (b43)
  • asadmin start-domain
  • asadmin enable-secure-admin
  • asadmin stop-domain
  • asadmin start-domain
  • open Safari web-browser and try to connect to the admin console via https on port 4848

Result: the admin console GUI won't load: error 404: "Failed to open page"

The result is the same whether you use Glassfish's own self-signed certificate or if you use an authority signed certificate.

On Firefox everything works perfectly. It connects to the admin console GUI just fine.

No error or exception can be found in server.log.



psartini added a comment - 29/Jul/11 01:03 PM

Same problem here. After "enable-secure-admin" it is not possible to log in.

Strange: neither chrome 11 nor firefox 5.0 work.
BUT it works with konqueror 4.6.5

I had this problem several times, on linux and solaris boxes. Always using the ZIP distribution.
Maybe the installer sets something up that is needed for this command to work?


Tim Quinn added a comment - 29/Jul/11 02:28 PM

Are you saying that all the combinations that fail with the zip distribution work correctly when you use the installer?

What exact version of Java are you using? Please look at the beginning of the server.log file to see where it is getting Java from and verify what version that is.

I still cannot reproduce this problem. I unzipped the b43 zip distribution on a Linux system and running through the steps listed above works fine for me when I browse remotely. I tried both Firefox 5.0.1 and Safari 5.0.6 from Mac OS X 10.5.8 (yes, Leopard).


psartini added a comment - 29/Jul/11 03:09 PM

No - I did not try the installer as it is unuseable slow over the internet.

My java version on this srv is 1.6.0_21
But I have seen this issue with 1.6.0_24 on another server as well.

The log files do not even show a single line - its like the port is closed. With konqueror, everything works (except some gui issues).


psartini added a comment - 29/Jul/11 03:10 PM

one note that might be important: I am always creating a new domain - and do not use domain1.


Tim Quinn added a comment - 29/Jul/11 03:25 PM

As you might know there are issues related to SSL in Java releases prior to 1.6.0_24. Is upgrading Java on that system a possibility?

(I realize you said that this problem occurs on another server running _24 already.)

Do you run the browser on the same system where the server is running?

If not, it might be useful for you to try an asadmin command remotely after you enable secure admin and restart the server. For example, try something simple like

asadmin --host where-your-server-runs uptime

from the same host where you are running the browsers that are accessing

asadmin will prompt you to accept the self-signed certificate that the server uses to identify itself, but once you do asadmin will accept that certificate without asking you again.

If you are running the browsers remotely from the server, then finding out if remote asadmin works might help to narrow down where the problem is. If you are running the browsers from the same system then this added test probably won't tell us much.

Thanks for the update about creating the new domain. That might be significant but it's not yet clear exactly how. When you unzip the distribution, the "built-in" domain1 uses the self-signed cert that was created when the distribution was built. Even if you unzip multiple times you still use the same cert. Creating a new domain, on the other hand, also creates a new self-signed cert each time.

I don't suppose there is anything in the browser error logs?


ref added a comment - 29/Jul/11 03:48 PM

Just a quick comment (don't have much time right now):

I'm also still having the same issue (even with GlassFish 3.1.1). My java version is 1.6.0_26. So the problem doesn't seem to be related to having an older java version installed.

When I initially submitted the bug report, I had the problem on a FreeBSD box. Tested it later on a Linux (Debian) box and I'm still having the same problem.

Tim Quinn: I don't understand what you mean by "running browser remotely', but I use the asadmin command remotely (from the Macs which have the browser problem) on a daily basis without any problems.

Most Macs have also been updated to Lion by now, if that helps.

I can do some more tests later if you want.


Tim Quinn added a comment - 29/Jul/11 04:09 PM

All I meant by "running the browser remotely" was launching the browser on system A and connecting to http://B:4848 (some other system). The alternative is running the browser locally, that is launching it on system A and connecting to http://A:4848 (or localhost:4848).


psartini added a comment - 29/Jul/11 04:17 PM

I will try to upgrade the java version later - but I am quite sure that its not the issue.

The browser runs on another machine in the internet, I am accessing the admin gui from our LAN.
Doing remote administration with asadmin works from my local machine after acceppting the certificate.

asadmin does work from the host machine as well btw.

If you mean the Error Log from firefox, it does not show anything. Not sure if there are other logs around.. does not print to the console.


Tim Quinn added a comment - 29/Jul/11 05:13 PM

I don't know if this will help us, but when you have a chance could you turn on Live HTTP Header display in Firefox? That will at least let us see what, if any, traffic is flowing between the browser and the server.


ref added a comment - 29/Jul/11 05:16 PM - edited

Tim McQuinn: I always run the browser remotely. (server: FreeBSD or Linux; client: OS X).

  • Running the browser (Lynx) locally works like a charm.
  • Running Safari on OS X remotely doesn't work.
    a) On some machines it doesn't work at all (timeout or 404)

b) On others it starts to load the site and I get to see some content but it always asks me for a certificate:

"The website <name> requires a client certificate.
-----------------------------------------
This website requires a certificate to validate your identity. Select the certificate to use when you connect to this website, and the click Continue."

And this is where I get stuck.

  • Works perfectly when using Firefox on OS X.

UPDATE: On one Mac it works perfectly when using Safari.

UPDATE 2: Found something interesting:
On one of the Macs where the GUI admin console requires me to select a certificate, I just added a new item to my OS X keychain (URL of my admin GUI with username and password, example: https://myserver.tld:4848 with usr/pw) and tried to access the admin console again:

  • It asks me one time to provide a certificate
  • I cancel/ignore
  • It works! I can access the admin console

UPDATE 2b:
The keychain contained already an item for https://myserver.tld:8181

  • I delete that keychain item (so that there's no more item for the GlassFish server and domain)
  • I try again to access the admin GUI using Safari
  • It asks me one time to provide a certificate
  • I cancel/ignore
  • Works fine!

Tim Quinn added a comment - 29/Jul/11 06:14 PM

It sounds as if there might be a couple things going on here which different browsers might handle differently.

The server is identifying itself to your browser using a certificate. If it is a self-signed cert (which is the default) then most browsers warn you - at least once - asking you whether you want to trust that self-signed cert or not. You also might have the option of remembering that decision for that cert or having the browser ask you every time it receives that cert from the server.

Separately from that, after you enable secure admin the server allows (but does not require) the client (browser) to also authenticate itself to the server using a cert instead of prompting for an admin username and password. This should be an option to you, rather than a requirement. It sounds like that is working for you based on your updates.


ref added a comment - 29/Jul/11 10:24 PM

I use a root-signed certificate. But the problem has been the same with a self-signed certificate.

It indeed looks like a browser issue and my problem has finally been resolved.

But what's strange is the fact that it has worked fine until GlassFish 3.1 got released.


Tim Quinn added a comment - 29/Jul/11 10:38 PM

ref,

Beginning with 3.1 GlassFish enforces the restriction that you must enable secure admin before it will accept remote admin requests. When you enable secure admin GlassFish automatically uses SSL/TLS to encrypt the admin traffic between the admin client (asadmin or browsers) and the server. And part of SSL/TLS is this whole certificate business, asking you (as the user of the browser or asadmin) whether you trust the server's certificate and what happens if you make a client cert available to your browser for it to send to the server.

That's why you see the difference from 3.0.1 to 3.1 (and 3.1.1).


Tim Quinn added a comment - 11/Nov/11 05:18 PM

Because I cannot reproduce this, and the symptoms vary for the original poster from one environment to the next, I'm going to close this bug as not reproducible.

If you find that this issue recurs reliably please re-open it.