Monthly Archive: January 2010

Troubleshooting SSL issues

Signature verification failed because RSA key public exponent [3] is too small

RSA Keys with Public Exponent results in faulty signature verification on WLS. Having so low exponent is considered as security vulnerability; hence keys with low exponents are not supported by WLS. However if we need to bypass this behavior, we can use the following flag Illegal key size or default parameters

This exception is encountered while using strong encryption such as AES256. We can overcome this by downloading the unrestricted jurisdiction policy files from the JVM vendor site and place it under jre/lib/security folder.

NEW ALERT with Severity: FATAL, Type: 70

We get this alert when the the party communication with Weblogic Server is using a different version of SSL. We need to check the Handshake Message for the version of SSL used.

Using this flag to specify the version of SSL at WLS can be helpful.

NEW ALERT=with Severity: FATAL, Type: 42

This alert means that the certificate presented to WLS is not trusted. It can be resolved by importing the certificate into the trust store of Weblogic Server.

HANDSHAKE_FAILURE alert received from localhost –

Most of the time its because of HOST NAME VERIFICATION.
Ignore Host Name Verification by setting this flag for Admin & Managed Server

And this in the startNodeManager.cmd

Sometime when the root certificate does not meet the basic constraint, i.e. even when the issuer and the owner is the same, the criticality is not true

ObjectId: Criticality=false

To allow WLS to accept such certificates we need to pass on this flag PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.113549.1.1.11

The root problem is the Certicom SSL does not support SHA256 algorithm, which is required with the trusted certificates of “ttelesecglobalrootclass2ca” and “ttelesecglobalrootclass3ca”

A fix is included in JDK 1.6.0_13 wherein WLS just ignores these certificates.

Trust failure (68): CERT_CHAIN_INCOMPLETE

We encounter this issue when the Weblogic Server is not able to verify the chain of certificates presented to it. From the debug message we can check the certificates and check their order in the chain. We can also check the trust store for the root and intermediate certificates on the signing authority of the certificates.
We can use this to validate the certificate chain using

java utils.ValidateCertChain -jks alias storefilename [storePass] the trustAnchors parameter must be non-empty

We need to specify the trustore as a JAVA OPTION
Or specify it as a System Property in the code


PKIX path building failed: unable to find valid certification path to requested target

Pass the keystore in the java options.

-Dssl.debug=true Illegal key size

Try adding the following jvm option. This will make Weblogic Server FIPS 140-2 compliant. Inbound closed before receiving peer’s close_notify: possible truncation attack?

This issue is fixed in 12.1.2
For 1035 and 1036 apply patch for BUG 13351178.

weblogic.wsee.jaxrpc.soapfault.WLSOAPFaultException: Failed to receive message FATAL Alert:BAD_CERTIFICATE – A corrupt or unuseable certificate was received.

Add the following JVM Options to the server

Upgrade the client to use the same version of Java 7 as the webservices.
Ensure that both the client and the webservices were using unlimited strength encryption. handshake alert:unrecognized_name

The issue is because of introduction of Server Name Indication in JAVA SE 7 update 2.
It can be disabled with the following flag.

To resolve it make sure your webserver has virtual hostname set correctly. Unable to process PreMasterSecret, may be too big” ?

This looks to a jdk isssue, following jdk bug matches the description.

Configuring OpenDS with Weblogic Server

Download Install and Configure OpenDS.

I used the following LDIF as BASE while installing OpenDS.

dn: dc=oracle,dc=com
dc: oracle
objectClass: domain
objectClass: top

dn: ou=TEST, dc=oracle,dc=com
ou: TEST
objectClass: organizationalUnit
objectClass: top

dn: cn=faisal,ou=TEST, dc=oracle,dc=com
uid: faisal
userPassword:: e1NTSEF9dnhBYUZKRzBONmwzWTdRMHBQRmdiczZrRHd5VUNwWCtCQTdlaHc9PQ
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Faisal
sn: Khan
cn: faisal

dn: cn=testuser,ou=TEST, dc=oracle,dc=com
uid: testuser
userPassword:: e1NTSEF9YXpZckZodWpla1FjWUNqcFJDQlRUeFRjOGNPa0NtaTF1a1hqWUE9PQ
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: testuser
sn: testuser
cn: testuser

dn: cn=TestGroup,ou=TEST, dc=oracle,dc=com
description: TestGroup
objectClass: groupOfUniqueNames
objectClass: top
uniqueMember: cn=faisal,ou=TEST,dc=oracle,dc=com
cn: TestGroup

Create an LDAP Authenticator.

Home >Summary of Security Realms >myrealm >Providers > Create New LDAPAuthenticator.


In the Provider Specific Tab provide the following details:

PORT : 1389
Principal : cn=faisal,ou=TEST, dc=oracle,dc=com
User Base DN : ou=TEST, dc=oracle,dc=com
Credentials : XXXXXXXXXXX
Group Base DN : ou=TEST, dc=oracle,dc=com

Leave the rest as default.

Now go to

Home >Summary of Security Realms >myrealm >Providers >Realm Roles
Expand Global Roles -> Expand Roles -> Click on View Role Conditions of the Admin Role -> Click on Add Conditions -> Select User in Predicate List -> Click Next -> In User Argument Name ADD faisal and FINISH -> Click Save

Change the control flag of the Default Authenticator as SUFFICIENT.

Log out and log in as faisal !


<sec:authentication-provider xsi:type=”wls:ldap-authenticatorType”>
<wls:principal>cn=faisal,ou=TEST, dc=oracle,dc=com</wls:principal>
<wls:user-base-dn>ou=TEST, dc=oracle,dc=com</wls:user-base-dn>
<wls:group-base-dn>ou=TEST, dc=oracle,dc=com</wls:group-base-dn>


SSL Vulnerabilites

SSL Server allows Anonymous Authentication Vulnerability

This basically means that the client will be able to connect to the Server without using any authentication algorithm. Some SSL Ciphers allow anonymous authentication. Choosing the right cipher suites as explained in an earlier post, and disabling null cipher from the admin console can help mitigate this risk.

SSL Server Allows Clear text Communication Vulnerability

This vulnerability depends upon the cipher suites used, as some cipher suites allow clear text communication. If no cipher suite is specifically mentioned in the config.xml file, then the cipher suites that allow clear text communication are enabled (as well as those that do not allow clear text).

To prevent clear text communications, avoid TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA, as these two cipher suites have 0 Symmetric Key Strength. For a list of allowed cipher suites, see the previous post. The values assigned here will allow 56 as well 128 bit encryption.

TLS Protocol Session Renegotiation Security Vulnerability

The details of the vulnerability can be found here
If u have applied the latest Critical Patch Update, you should b fine.
Find more details here