glassfish
  1. glassfish
  2. GLASSFISH-17132

CLONE -Admin console not loading after enabling secure-admin

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Server: FreeBSD 8.2 x64
      Client: Mac OS X 10.6.7

      Description

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

        Activity

        Hide
        psartini added a comment -

        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?

        Show
        psartini added a comment - 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?
        Hide
        Tim Quinn added a comment -

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

        Show
        Tim Quinn added a comment - 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).
        Hide
        psartini added a comment -

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

        Show
        psartini added a comment - 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).
        Hide
        psartini added a comment -

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

        Show
        psartini added a comment - one note that might be important: I am always creating a new domain - and do not use domain1.
        Hide
        Tim Quinn added a comment -

        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?

        Show
        Tim Quinn added a comment - 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?
        Hide
        ref added a comment -

        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.

        Show
        ref added a comment - 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.
        Hide
        Tim Quinn added a comment -

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

        Show
        Tim Quinn added a comment - 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).
        Hide
        psartini added a comment -

        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.

        Show
        psartini added a comment - 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.
        Hide
        Tim Quinn added a comment -

        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.

        Show
        Tim Quinn added a comment - 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.
        Hide
        ref added a comment - - 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!
        Show
        ref added a comment - - 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!
        Hide
        Tim Quinn added a comment -

        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.

        Show
        Tim Quinn added a comment - 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.
        Hide
        ref added a comment -

        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.

        Show
        ref added a comment - 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.
        Hide
        Tim Quinn added a comment -

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

        Show
        Tim Quinn added a comment - 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).
        Hide
        Tim Quinn added a comment -

        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.

        Show
        Tim Quinn added a comment - 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.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            psartini
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 2 hours
              2h
              Remaining:
              Remaining Estimate - 2 hours
              2h
              Logged:
              Time Spent - Not Specified
              Not Specified