Security

This section describes known issues and associated solutions related to Enterprise Server and web application security and certificates.

Expired Root CA for CN=GTE CyberTrust Root 5, OU=GTE CyberTrust Solutions, Inc. (17405362)

Description

During startup of an Enterprise Server instance, an expired certificate is reported in the instance's server.log log file as follows:

The "GTE CyberTrust Root 5" certificate expired on August 15th 2013 

The log file shows the validity of the certificate as follows:

Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
...
 Validity: [From: Fri Aug 14 15:50:00 BST 1998,
  To: Thu Aug 15 00:59:00 BST 2013]

Solution

The solution depends on whether the instance is configured to use a server SSL certificate that uses this certificate as part of its trust path.

• If the instance is not configured this way, ignore the warning. The functionality of the instance is unaffected.

  If no server certificate has been signed by GTE CyberTrust Root 5 certificate, delete the certificate from the truststore. For instructions, see To Delete the GTE CyberTrust Root 5 Certificate From the Truststore.

  ---

  Note - In the latest releases of Java SE 6 and Java SE 7, this certificate is no longer present by default. The only GTE certificate has the alias gtecybertrustglobalca and does not expire until August 2018.

  ---

• Otherwise, contact the issuing certificate authority (CA) to resolve the issue.

  The CA will either reissue the certificate with an up to date or alternate root certificate or will provide an updated certificate to install in the truststore.

  To determine that the new certificate is correct, confirm that the issuer's subject is as follows:

  CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc."

To Delete the GTE CyberTrust Root 5 Certificate From the Truststore

1. Back up the existing certificate database files in the domain's configuration directory.
   1. Change to the domain's config directory.

      prompt% cd as-install/domains/domain-name/config/

   2. Copy the certificate database files.

      The files to copy depend on the type of the keystore.

      • For a JKS keystore, copy the cacerts.jks file.
      • For an NSS keystore, copy these files:

        • cert8.db

        • key3.db

2. Delete the gtecybertrust5ca certificate from the certificate database.
   • For a JKS keystore, use the keytool command for this purpose.

     prompt% keytool -delete -alias gtecybertrust5ca -keystore cacerts.jks

     When prompted, provide the master password of the domain.

   • For an NSS keystore, use the certutil command for this purpose.

     prompt% certutil -D -d . -n gtecybertrust5ca

     When prompted, provide the master password of the domain.

3. If additional domains are to be created from the existing Enterprise Server installation, delete the expired certificate from the template keystores.

   Deleting the expired certificate prevents the certificate from being propagated to new domains.

   1. Back up the existing template keystores.
      1. Change to the templates directory of your Enterprise Server installation.

         prompt% cd as-install/lib/install/templates

      2. Copy the files for the template keystores.

         The files to copy depend on the type of the keystore.

         • For a JKS keystore, copy the cacerts.jks file in the current working directory and in the ee subdirectory of the current working directory.
         • For an NSS keystore, copy these files in the current working directory and in the ee subdirectory of the current working directory:

           • cert8.db

           • key3.db

   2. Delete the gtecybertrust5ca certificate from the template keystores in the current working directory and in the ee subdirectory of the current working directory.
      • For a JKS keystore, use the keytool command for this purpose.

        prompt% keytool -delete -alias gtecybertrust5ca -keystore cacerts.jks

        prompt% keytool -delete -alias gtecybertrust5ca -keystore ee/cacerts.jks

        When prompted, provide the master password of the domain.

      • For an NSS keystore, use the certutil command for this purpose.

        prompt% certutil -D -d . -n gtecybertrust5ca

        prompt% certutil -D -d ee -n gtecybertrust5ca

        When prompted, provide the master password of the domain.

4. Propagate the changes to the DAS and all Enterprise Server instances in the domain.
   1. Stop the domain and all Enterprise Server instances in the domain.
   2. Start only the domain, not the instances in the domain.
   3. After the domain is started, start all Enterprise Server instances in the domain.

      ---

      Note - To ensure that the instances are synchronized with the DAS, you must start the instances individually, even if the instances are members of a cluster. Starting a cluster does not synchronize the instances in the cluster.

      If you start an instance by starting the node agent for the host where the instance resides, you must specify the --syncinstances option of the start-node-agent command. Otherwise, the instance is not synchronized.

      ---

Modify Policy Files for Existing Domains (17419736 and 17574160)

Description

As a result of changes to the security implementation in JDK 1.6.0_51, additional permissions are required to prevent some operations from failing. For example, an attempt by an application to perform a transaction might fail with the java.io.SerializablePermission enableSubclassImplementation exception.

Solution

For each existing domain, add the following permissions to the grant block for the basic set of permissions in the domain-dir/config/server.policy file:

permission java.io.SerializablePermission "enableSubclassImplementation";
permission java.lang.RuntimePermission "accessClassInPackage.com.sun.org.apache.xml.internal.utils";
permission java.lang.RuntimePermission "accessClassInPackage.com.sun.org.apache.xerces.internal.dom";
permission java.lang.RuntimePermission "accessClassInPackage.com.sun.org.apache.xerces.internal.jaxp";

CA Certificate bundled with Enterprise Server v2.1.1 has expired (12287499)

Description

The CA certificate bundled with Enterprise Server v2.1.1 has expired since Jan 08, 2010. Hence some SEVERE log messages may be observed while starting the domain.

Solution

These messages are harmless but can be eliminated. Remove the expired certificate from the keystore. To remove the certificate from the JKS keystore, use the following command:

keytool delete -alias verisignserverca -keystore domain-dir/config/cacerts.jks

To remove the certificate from the NSS keystore, use the following command:

certutil -D -n verisignserverca -d domain-dir/config

OutofMemory Error in SSL Scenarios During Heavy Stress (JDK 6 Issue 23)

Description

A JDK bug (See: https://jdk6.dev.java.net/issues/show_bug.cgi?id=23) in JDK6 Sun PKCS11 Provider could cause an OutOfMemoryError when running certain SSL scenarios under heavy stress.

Solution

If you run into this issue, remove sun.security.pkcs11.SunPKCS11 provider from the java.security file in your JRE installation.

AIX: WSS dynamic encrypt key test failed due to server side certification validation error (6627379)

Description

On the AIX platform, dynamic encryption for the determination of an encryption key for a response is failing. The failure occurs during the validation of the certificate on the server side.

In response to the failure, the following error messages are written to the server's log file server.log:

Unable to validate certificate

Error occurred while resolving key information
com.sun.xml.wss.impl.WssSoapFaultException: Certificate validation failed

Solution

Install Metro 1.1 on Enterprise Server v2.1.1

AIX: @RunAs at EJB module authorization test failed AccessLocalException: Client not authorized (6627385)

Description

A method in an enterprise bean whose run-as, or propagated, security identity is defined by using the @RunAs annotation attempts to invoke a method in another enterprise bean. If no run-as principal is defined in the sun-ejb-jar.xml deployment descriptor file, the attempt might fail with a javax.ejb.AccessLocalException exception.

javax.ejb.AccessLocalException: Client not authorized for this invocation.

Solution

In the sun-ejb-jar.xml deployment descriptor file, define in the principal-name element the principal name for which the run-as role specified.

SSL termination is not working (6269102)

Description

SSL termination is not working; when Load Balancer (Hardware) is configured for SSL termination, the Enterprise Server changes the protocol from https to http during redirection.

Solution

Add a software load balancer between the hardware load balancer and the Enterprise Server.

Socket connection leak with SSL (6492477)

Description

Because of a JVM bug, there is a leak issue with some JDK versions when security-enabled is set to true on an HTTP listener. Specifically, the steps to reproduce this bug are as follows:

1. Set security-enabled to true on the HTTP listener:

   <http-listener acceptor-threads="1" address="0.0.0.0" 
   blocking-enabled="false" default-virtual-server="server" enabled="true" 
   family="inet" id=" http-listener-1" port="8080" security-enabled="true" 
   server-name="" xpowered-by="true">

2. Comment out stopping domain at the end of quicklook tests.

3. Run quicklook tests.

4. Check socket usage:

   netstat -an | grep 8080

   The following are shown to be in use:

   *.8080               *.*                0      0 49152      0 LISTEN
   *.8080               *.*                0      0 49152      0 BOUND

This issue is tracked on the GlassFish site at http://java.net/jira/browse/GLASSFISH-849.

Solution

Upgrade to the latest JDK version.

General Vulnerability Assessment (Issue 17287)

Description

An unspecified vulnerability in Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Administration. See http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0807.

Solution

Upgrade to Oracle GlassFish Server 3.1 or later.