Monday Jan 11, 2010

SEC5054: Certificate has expired

One of the authority certificates in the Glassfish truststore (i.e., cacerts.jks) expired on Jan 7, 2010. On startup, Glassfish will log a message (to server.log) indicating that the following certificate has expired.

Version: V1
  Subject: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
  Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

  Key:  SunPKCS11-Solaris RSA public key, 1000 bits (id 17891456, session object)
  public exponent: 
  Validity: [From: Tue Nov 08 19:00:00 GMT-05:00 1994,
               To: Thu Jan 07 18:59:59 GMT-05:00 2010]
  Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
  SerialNumber: [    02ad667e 4e45fe5e 576f3c98 195eddc0]

The expired authority certificate will be removed in update 18 of Java SE 6. It will also be removed from the Glassfish truststore.

No action is required on your part, as all certificates issued under the expired authority certificate have also expired.

If you would like to stop your installation of Glassfish from reporting the presence of the expired authority certificate, you can use keytool to remove the certificate from the Glassfish truststore.

=> cd domains/domainX/config
=> cp cacerts.jks
=> keytool -delete -keystore cacerts.jks -alias verisignserverca
Enter keystore password: 

to prevent the expired cert from reappearing in subsequently created domains, The cert should also be removed from the template truststore.

=> cd glassfish/lib/templates
=> cp cacerts.jks
=> keytool -delete -keystore cacerts.jks -alias verisignserverca
Enter keystore password: 

For more details on the expired certificate please see:

The Glassfish V3 admin guide may be found at:

For versions and installations of Glassfish that use Network Security Services, i.e., NSS, the certutil command may be used to remove the expired certificate from the cert8.db file, and the corresponding cert8.db template file. For example:

==> cd directory-where-cert8.db-is-located
==> cp cert8.db
==> certutil -D -n "Verisign/RSA Secure Server CA"

Tuesday Jan 06, 2009

Defining Security Constraints on Content under Glassfish Docroot

This entry describes how to define security constraints on content served by the default web module. [Read More]

Friday Nov 07, 2008

Prelude includes Portable, In-Memory JACC Provider

We made some enhancements in Prelude to improve JACC policy provider replacability, and we added a new portable in-memory JACC Policy provider that can be configured as an alternative to the file-based JACC Policy provider. The file-based provider is configured by default. To enable the in-memory provider, do the following:
  • stop the application server (i.e., asadmin stop-domain)
  • edit domain.xml and add or change the security-service element to define the attribute jacc="simple"
  • restart the application server. (i.e, asadmin start-domain)
The in-memory provider was developed both to provide a simpler and more performant alternative, as well as to serve as a sample to help others develop their own providers. Portability was achieved by defining a JACCRoleMapper interface, and by defining the provider such that it can be trained (via a system property, i.e., to use a system specific implementation of the JACCRoleMapper interface. The source of the in-memory provider is available in the project repository.

Tuesday Jan 22, 2008

Pluggable Authentication in the Glassfish Web Tier

You can inject a new network authentication mechanism in the Glassfish Servlet container by:
  • implementing a JSR 196 server authentication module (i.e., a SAM), and
  • configuring the SAM as a message-security-provider via the Glassfish admin console, and
  • binding the SAM for use by your application via sun-web.xml.

A SAM differs from a custom realm in that the SAM can control the HTTP authentication dialog, while a realm is typically used by a system controlling the dialog (such as a SAM) to validate or augment credentials extracted from the exchanged messages. JSR 196 is also used by (and available within) the client and server-side web service pipelines of the Glassfish METRO stack.[Read More]

Tuesday Jan 15, 2008

How to define an ANYONE role in Glassfish

An ANYONE role is a role that is granted to every authenticated user and only to authenticated users. Any Glassfish realm may be configured such that it assigns one or more group principals as a side effect of any successful authentication at the realm. Any application role that is mapped to one of the assigned group principals can be used as an ANYONE role. An application defines an ANYONE role as follows:

  • configure the "assign.groups" property of the Glassfish realm used for the application. This can be accomplished by using the admin console. Login to the console and navigate to the realm specific configuration screen found under configuration => security => realms. In the "Assign Group:" input box on that screen, specify the name of the group principal that you want to be assigned by the realm.
  • declare a role either within the corresponding portable deployment descriptor, or by using either the @declareRoles or @rolesAllowed annotations.
  • map the assigned group principal to the declared role, as described in Principal 2 role mapping and Glassfish. If the default mapping is employed to map the group principal to the role, the name of the role must be equivalent to that of the assigned group. Otherwise, the role may be given any name.

Tuesday Dec 18, 2007

Policy Files, The SecurityManager, and Glassfish Access Control

Glassfish uses Jacc for its container access decisions. The container access decisions are performed independent of whether a System SecurityManager is configured for the Glassish Server. You should not define an unqualified grant of AllPermission in server.policy, .java.policy, or in any of the policy files identified in jre/lib/security/ JACC leverages the replacability afforded by the JRE to enable replacability of the container policy decision subsystem.[Read More]

Friday Nov 16, 2007

principal 2 role mapping and Glassfish

When you deploy a portable application or module on Glassfish, you don't need to define an application specific principal to role mapping. Glassfish allows you to activate a default mapping that will be applied on behalf of all applications that are (subsequently) deployed without an application specific mapping. This feature of glassfish is described in more detail in: Roles, Principals, and Principal to Role Mapping. The default mapping is canonical in that it maps groups to same-named roles. For example group principal "user" is mapped to role "user". Applications or modules deployed before the default mapping is activated, are unaffected.



« July 2016