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
        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.
        Hide
        johnhd added a comment - - edited

        Bumping a super old thread here, but...

        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!

        I've reproduced this on Chrome 44.0.2403.155 (64-bit) and GlassFish Server Open Source Edition 3.1.2.2 (build 5)

        The workaround is the same- I have to hit cancel. If I hit "ok", I'll eventually time out.

        I have client-auth disabled for the admin http listener which I believe is the default-on-install since we use asadmin enable-secure-admin (which is no longer mentioned in the documentation?)

        It's behaving as if it's prompting client-auth though?

        I'm seeing about taking a TCPdump as well, but wanted to see if there was any traction on this?

        EDIT: Wanted to add that I tried adding my workstation's public certificate to glassfish's truststore, restarted, and then was able to access the admin screen when I hit OK- no timeout.

        Show
        johnhd added a comment - - edited Bumping a super old thread here, but... 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! I've reproduced this on Chrome 44.0.2403.155 (64-bit) and GlassFish Server Open Source Edition 3.1.2.2 (build 5) The workaround is the same- I have to hit cancel. If I hit "ok", I'll eventually time out. I have client-auth disabled for the admin http listener which I believe is the default-on-install since we use asadmin enable-secure-admin ( which is no longer mentioned in the documentation? ) It's behaving as if it's prompting client-auth though? I'm seeing about taking a TCPdump as well, but wanted to see if there was any traction on this? EDIT: Wanted to add that I tried adding my workstation's public certificate to glassfish's truststore, restarted, and then was able to access the admin screen when I hit OK- no timeout.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            psartini
          • Votes:
            0 Vote for this issue
            Watchers:
            3 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