Glassfish Admin Console loading blank page

Question

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

Cita

Try comparing the domain.xml maybe you'll find something there. – Pluton

I had the same error. Left my SSL as is, but made a change in the Domain.xml and changed the admin-listener's back to s1as. I'm not writing an answer since I'm not 100% sure of the process nor the logic behind it. – Legality

@Legality Have you found any solution for it? I am getting same error – Centillion

@Abhi Nothing concrete thus far. It has always been something with the domain.xml file. Sometimes just restarting fixes it. I wish I could find something more definitive. – Legality

@blo0p3r: mine issue was because of default SSL certificates. I made some changes in default SSL certs which caused this issue. I don't know how it got fixed, I just did same changes in certs again and it started working. – Centillion

Answer 1

I've had this happen to me when I enable "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>

Bide

I just reviewed my domain.xml file and did not find any reference to that setting, so presumably that's not my issue. Though there may be some similar option that's causing me grief. At the very least, this gives me something to look into. Thanks. – Cita

What version were you using on this particular answer? – Boundless

3.1.2.2 (build 5) – Bide

Answer 2

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.

Brat

I have done this, but it's saying "Your connection is not private", Why it is changed to https? – Nahshunn

Answer 3

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.

Boundless

We ended up moving to the Payara server not too long ago, and the problem went away. Payara fixed a number of other lingering problems we'd been having with Glassfish and was essentially a transparent drop-in replacement. – Cita

Answer 4

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

3. 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.
4. Delete the former certificate from truststore

keytool -delete -alias s1as -keystore ./path/to/your/cacerts.jks

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

Libbi