Reputation: 802
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
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
.
127.1:4848
before payara upgrade)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
s1as
and the same fingerprint you got from step 1. Or pipe the previous command to grep
filtering the SHA256
fingerprint from step 1.keytool -delete -alias s1as -keystore ./path/to/your/cacerts.jks
/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
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
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
Reputation: 4517
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>
Upvotes: 6