Signature verification failed because RSA key public exponent  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
java.security.InvalidKeyException: 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 – 127.0.0.1.
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: 184.108.40.206 Criticality=false
To allow WLS to accept such certificates we need to pass on this flag
java.security.cert.CertificateParsingException: PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.1135220.127.116.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]
java.security.InvalidAlgorithmParameterException: 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: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Pass the keystore in the java options.
-Dssl.debug=true -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=faisal_trust.jks -Djavax.net.ssl.keyStore=faisal.jks -Djavax.net.ssl.keyStorePassword=password -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Djava.protocol.handler.pkgs=weblogic.net
java.security.InvalidKeyException: Illegal key size
Try adding the following jvm option. This will make Weblogic Server FIPS 140-2 compliant.
javax.net.ssl.SSLException: 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 javax.net.ssl.SSLKeyException: 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.
javax.net.ssl.SSLProtocolException: 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.
javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big” ?
This looks to a jdk isssue, following jdk bug matches the description.
java.lang.RuntimeException: javax.net.ssl.SSLException: Received fatal alert: unexpected_message
This is due to a jdk1.7 bug. It can be remediated by applying the flag below.
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
This happens when the application running on JDK still uses TLS1.0 As a temporary work around we can enable TLS protocol by commenting the line below in java.security file
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024,
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
We just modified our dev environment to include -Dweblogic.security.SSL.enforceConstraints=off because we were getting a Fatal error ; <Connection failure.javax.net.ssl.SSLProtocolException: FATAL Alert:BAD_RECORD_MAC – A record was received with an incorrect MAC. but we just found the following online: Oracle does not recommend using this option in a production environment.Instead, purchase new CA certificates that comply with the IETF RFC 2459standard. CA certificates from most commercial certificate authoritiesshould work with the default strong option.What do you think? What is our risk if we implement this in production?
By default WLS does not accept certificates which has the Criticality of BASIC Constraints set to false for root certificates.ObjectId: 18.104.22.168 Criticality=falseBasicConstraints:[CA:truePathLen:0]WLS follows the industry standards, but this limits the apllications running on it.To overcome this it provided the flag -Dweblogic.security.SSL.enforceConstraints=offThis flag does not affect the certificate verification process, hence I dont see it as a security threat, even in production.There are some research papers available on the internet, you can go throgh them.
Hi Khan ,
we are accessing third party server through our weblogic
then we are getting bad certificate error.please need help for this
when are u getting bad certificate error?
enable SSL Debug on the server and paste the handhake message here
I added -Dweblogic.security.SSL.enforceConstraints=off at startup script but still i see
error coming as
2012-12-04 10:14:32,023 ERROR [[ACTIVE] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’] com.xyz.abc.ejbadaptor.Service – Fail to get Information for xyz [Ljava.lang.String;@136b0f0
java.rmi.RemoteException: SOAP Fault:javax.xml.rpc.soap.SOAPFaultException: Failed to send request
javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain received from servicemngr-pt168.tsl.telus.com – x.y.z.l was not trusted causing SSL handshake failure.
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknown Source)
can someone help on this
Apologies for the late reply.
I would import the root CA of the server its connecting to into my trust key store.
It could be either the default JDK keystore or custom trust key store depending on the usage.
You can use KeyTool utility to import the same.
keytool -import -file rootCA.cer -alias RootCA -keystore trust.jks -storepass password
I am getting same error. Did you get a solution to your problem.
Can you please share the solution to this problem.
I am getting the following error when invoking google reCAPTCH secured site from my weblogic 10.3 Web applciation… Any idea?
[Security:090477]Certificate chain received from http://www.google.com – 22.214.171.124 was not trusted causing SSL handshake failure.
You need to import google’s certificates in your servers trusstore.
What is the keystore configuration you have as of now?
Comments are closed.