Steve Ferguson
Steve Ferguson

Reputation: 802

Glassfish Admin Console loading blank page

I'm having an issue logging in to the admin console for Glassfish 3.1.2 on one of four identically (at least that's the theory) configured domains on different servers. When I log in on the one that's not working, I get redirected to a blank page at:

https://{server}:{admin port}/j_security_check

It is accompanied by this log message:

[#|2013-02-18T09:58:02.912-0500|SEVERE|glassfish3.1.2|org.glassfish.admingui|_ThreadID=20;_ThreadName=Thread-2;|javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed; javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed; restRequest: endpoint=https://localhost:9048/management/domain/anonymous-user-enabled attrs={} method=GET|#]

Other information:

I have secure administration enabled, and the anonymous user disabled.

I can request https://{server}:{admin port}/management/domain using the same user/password and successfully pull up the REST interface. Requesting /management/domain/enable-anonymous-user does trigger the same problem (blank page, logged error).

I can run "asadmin -p {admin port}" with the same user/password and successfully run command line commands.

I seem to remember tracking this down at one point to the admin console attempting to pull in a file from a server on the sun.com domain, for which the SSL certificate had expired, but I can't seem to find the solution I applied at the time.

I've attempted to use the cacerts.jks file from one of the servers that's working, and that hasn't helped.

The expiration date on my s1as cert in keystore.jks is still 8 years out.

The date/time on the server is set correctly.

Thanks for any suggestions.

Steve

Upvotes: 5

Views: 11087

Answers (4)

helvete
helvete

Reputation: 2673

I encountered this after upgrading Payara server to a new version (4.1 to 5.2021.10, the versions shouldn't matter though)

Naturally newer Payara versions also carry newer localhost certificate (for admin-gui, etc.) with them.

As our application is dockerized and cacerts.jks truststore is a part of the the docker setup the localhost (s1as) certificate had to be updated.

There are perhaps more ways to do this, but I prefer the one using keytool.

  1. Look up your old instance certificate (for example in browser after reaching 127.1:4848 before payara upgrade)
  2. List trusted certificates in cacerts.jks. Provide a password to continue (this one in case you haven't already updated it)
keytool -list -keystore ./path/to/your/cacerts.jks
  1. Verify there is a certificate having alias s1as and the same fingerprint you got from step 1. Or pipe the previous command to grep filtering the SHA256 fingerprint from step 1.
  2. Delete the former certificate from truststore
keytool -delete -alias s1as -keystore ./path/to/your/cacerts.jks
  1. Add the new certificate. Get it for example using a browser like in step 1. again, but now the fresh one after upgrading payara. Store it as /tmp/localhost.pem
keytool -import -keystore ./path/to/your/cacerts.jks -trustcacerts -alias s1as -file /tmp/localhost.pem

Rebuild the application and you are golden.

Upvotes: 0

qualebs
qualebs

Reputation: 1379

Hi if you never found out a solution to this problem. I was able to work around it by enabling default principal to role mapping setting in my application by adding the following lines to glassfish-web.xml file found in your WEB-INF folder.

  <security-role-mapping>
    <role-name>roleName</role-name>
    <group-name>groupName</group-name>
  </security-role-mapping>

You can modify role name and group name accordingly depending on what you have in your application. The bug is still present in all glassfish releases to the time of writing this answer. But one observation I have made is that it does not show up in the glassfish server bundled with netbeans IDE.

Upvotes: 0

GeorgDangl
GeorgDangl

Reputation: 2192

It could be the issue described in this bug report.

Anissa Lam wrote on 03/Mar/2011 the following:

In v2, you enable https by just simply enable security on the admin-listener.
In v3, you have to run the enable-secure-admin command, and then restart the server. Then you can access the console by https, and http will also be redirected to https.
%asadmin start-domain 
%asadmin enable-secure-admin
%asadmin stop-domain 
%asadmin start-domain
then launch GUI.
Please do the above and if you still have problem, reopen the bug. thanks

This was the bug that caused it for me.

Upvotes: 2

Gus
Gus

Reputation: 4517

I've had this happen to me when I enable "Default Principal To Role Mapping":

Default Principal To Role Mapping

After I enable this and restart the domain, I'm never able to login again. I had to change the following line on domain.xml (with the domain stopped) :

<security-service default-principal-password="admin" activate-default-principal-to-role-mapping="true" default-principal="admin">

to this:

<security-service>

Upvotes: 6

Related Questions