Bo's blog

Tuesday, October 25, 2011

[Security:090477]Certificate chain received from yourhost – ip was not trusted causing SSL handshake failure

Issue:

OSB server has a proxy service which need to callout to another WS over ssl, and got the following issue.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>BEA-380000: General runtime error: [Security:090477]Certificate chain received from yourhost - ip was not trusted causing SSL handshake failure.</faultstring>
         <detail>
            <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
               <con:errorCode>BEA-380000</con:errorCode>
               <con:reason>General runtime error: [Security:090477]Certificate chain received from yourhost - ip was not trusted causing SSL handshake failure.</con:reason>
               <con:location>
                  <con:node>PipelinePairNode1</con:node>
                  <con:pipeline>PipelinePairNode1_request</con:pipeline>
                  <con:stage>stage1</con:stage>
                  <con:path>request-pipeline</con:path>
               </con:location>
            </con:fault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>


 



Solution:



need to import the certificate of yourhost to the OSB server.



1. to get the certificate, using browser browse the WSDL through https protocol and save the certificate file of the site.



2. using the following command to import certificate file saved from step 1 to truststore of weblogic.



keytool -import -v -noprompt -trustcacerts -alias rootcacert -file rootCA.cer -keystore /opt/bea/OSB1031_64/wlserver_1031_64/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase



keytool -list -v -keystore /opt/bea/OSB1031_64/wlserver_1031_64/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase



Trust store location %ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoTrust.jks


Trust store password DemoTrustKeyStorePassPhrase


Key store location %ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoIdentity.jks


Key store password DemoIdentityKeyStorePassPhrase


Private key password DemoIdentityPassPhrase

Labels: ,

Thursday, September 29, 2011

[J2EE Deployment SPI:260080]Unable to define application install directory


Using ant deploy task to deploy the app to Weblogic server(Windows) through Hudson server(Linux), failed due to the following issue:

deploy:
 [wldeploy] weblogic.Deployer -debug -verbose -upload -noexit -name TestApp -source /app/hudson/job1/workspace/dist/TestApp.war -targets AdminServer -adminurl t3://192.168.1.111:7001 -user weblogic -password ******** -deploy 


 [wldeploy] [BasicOperation.dumpTmids():689] :   {Target=AdminServer, WebLogicTargetType=server, Name=TestApp}, targeted=true
 [wldeploy] [BasicOperation.deriveAppName():139] : appname established as: TestApp
 [wldeploy]  
 [wldeploy] java.io.IOException: [J2EE Deployment SPI:260080]Unable to define application install directory at '/tmp/TestApp.war'. Directory could not be created or is a file.


Solution: check the folder /tmp on Hudson server and remove the TestApp.war from there.

Labels: ,

Thursday, September 22, 2011

Authentication denied: Boot identity not valid


Weblogic error when starting the server:


<Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.>


Follow the following steps:
1: remove the file boot.properties from directory servers/yourserver/security/.
2: remove the directory servers/yourserver/data/ldap .

start weblogic by command line, and it will prompt for username and password to boot.

create new file boot.properties in directory servers/yourserver/security, and put the following value and restart.
password=weblogic
username=weblogic

Out of the box, users are stored in WebLogic’s embedded LDAP. This means all “normal” users as well as the WebLogic administrative user typically named “weblogic” or “admin” are stored there. Additionally, groups are also stored in embedded LDAP. Users and groups are stored there because the embedded LDAP serves as the DefaultAuthenticator’s data store.


There’s one more critical piece about authenticators and that’s the Control Flag. Each authenticator has a Control Flag that can be set to REQUIRED, REQUISITE, SUFFICIENT, or OPTIONAL. Each flag indicates how the authenticator will be treated by the security framework and whether or not that authenticator has to be able to successfully authenticate the user or not. You can find an explanation of these flags here.
reference: common-problems-with-authentication-provider-configuration

Labels:

Friday, November 20, 2009

Configuring and Managing WebLogic JMS

Using WLST to Manage JMS Servers and JMS System Resources

The WebLogic Scripting Tool (WLST) is a command-line scripting interface that you can use to create and manage JMS servers and JMS system resources. See "Using the WebLogic Scripting Tool and WLST Sample Scripts in the WebLogic Scripting Tool.


Understanding System Modules and Subdeployments

A module is described by the jms-system-resource MBean in the config.xml file. Basic components of a jms-system-resource MBean are:

  • name—Name of the module.
  • target—Server, cluster, or migratable target the module is targeted to.
  • sub-deployment—A mechanism by which JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as a JMS server instance, WebLogic server instance, or cluster).
  • descriptor-file-name—Path and filename of the system module file.

The JMS resources of a module are located in a module descriptor file that conforms to the weblogic-jmsmd.xml schema. In Figure 6-1, the module is named myModule-jms.xml and it contains JMS resource definitions for a connection factory and a queue. The sub-deployment-name element is used to group and target JMS resources in the myModule-jms.xml file to targets in the config.xml. You have to provide a value for the sub-deployment-name element when using WLST. For more information on subdeployments, see "Targeting JMS Modules and Subdeployment Resources". In Figure 6-1, the sub-deployment-name DeployToJMSServer1is used to group and target the connection factory CConfac and the queue CQueue in the myModule-jms module.

For more information on how to use JMS resources, see "Understanding JMS Resource Configuration in Configuring and Managing WebLogic JMS.

Figure 6-1 Subdeployment Architecture

Subdeployment Architecture


How to Create JMS Servers and System Resources

Basic tasks you need to perform when creating JMS resources with the WLST are:

  • Start an edit session.
  • Create a JMS system module that includes JMS system resources, such as queues, topics, and connection factories.
  • Create JMS server resources.

After you have established an edit session, use the following steps configure JMS servers and system resources:

  1. Get the WebLogic Server MBean object for the server you want to configure resources. For example:
  2. servermb=getMBean("Servers/examplesServer")
        if servermb is None:
            print '@@@ No server MBean found'



  3. Create your system resource. For example:



  4. jmsMySystemResource = create(myJmsSystemResource,"JMSSystemResource")



  5. Target your system resource to a WebLogic Server instance. For example:



  6. jmsMySystemResource.addTarget(servermb)



  7. Get your system resource object. For example:



  8. theJMSResource = jmsMySystemResource.getJMSResource()



  9. Create resources for the module, such as queues, topics, and connection factories. For example:



  10. connfact1 = theJMSResource.createConnectionFactory(factoryName)




    jmsqueue1 = theJMSResource.createQueue(queueName)



  11. Configure resource attributes. For example:



  12. connfact1.setJNDIName(factoryName)
    jmsqueue1.setJNDIName(queueName)



  13. Create a subdeployment name for system resources . See Understanding System Modules and Subdeployments.For example:



  14. connfact1.setSubDeploymentName('DeployToJMSServer1')
    jmsqueue1.setSubDeploymentName('DeployToJMSServer1')



  15. Create a JMS server. For example:



  16. jmsserver1mb = create(jmsServerName,'JMSServer')



  17. Target your JMS server to a WebLogic Server instance. For example:



  18. jmsserver1mb.addTarget(servermb)



  19. Create a subdeployment object using the value you provided for the sub-deployment-name element. This step groups the system resources in module to a sub-deployment element in the config.xml. For example:



  20. subDep1mb = jmsMySystemResource.createSubDeployment('DeployToJMSServer1')



  21. Target the subdeployment to a server resource such as a JMS server instance, WebLogic Server instance, or cluster. For example:



  22. subDep1mb.addTarget(jmsserver1mb)




Listing 6-1 WLST Script to Create JMS Resources




"""
This script starts an edit session, creates a JMS Server,
targets the jms server to the server WLST is connected to and creates
a JMS System module with a jms queue and connection factory. The
jms queues and topics are targeted using sub-deployments.
"""

import sys
from java.lang import System

print "@@@ Starting the script ..."

myJmsSystemResource = "CapiQueue-jms"
factoryName = "CConFac"
jmsServerName = "myJMSServer"
queueName = "CQueue"

url = sys.argv[1]
usr = sys.argv[2]
password = sys.argv[3]

connect(usr,password, url)
edit()
startEdit()

//Step 1
servermb=getMBean("Servers/examplesServer")
    if servermb is None:
        print '@@@ No server MBean found'

else:




    //Step 2
    jmsMySystemResource = create(myJmsSystemResource,"JMSSystemResource")




    //Step 3
    jmsMySystemResource.addTarget(servermb)

    //Step 4
    theJMSResource = jmsMySystemResource.getJMSResource()

    //Step 5
    connfact1 = theJMSResource.createConnectionFactory(factoryName)
    jmsqueue1 = theJMSResource.createQueue(queueName)




    //Step 6
    connfact1.setJNDIName(factoryName)
    jmsqueue1.setJNDIName(queueName)





    //Step 7
    jmsqueue1.setSubDeploymentName('DeployToJMSServer1') 




    connfact1.setSubDeploymentName('DeployToJMSServer1')
    //Step 8
    jmsserver1mb = create(jmsServerName,'JMSServer')
    //Step 9
    jmsserver1mb.addTarget(servermb)

    //Step 10
    subDep1mb = jmsMySystemResource.createSubDeployment('DeployToJMSServer1')




    //Step 11
    subDep1mb.addTarget(jmsserver1mb)
.
.
.






How to Modify and Monitor JMS Servers and JMS Resources



You can modify or monitor JMS objects and attributes by using the appropriate method available from the MBean.




  • You can modify JMS objects and attributes using the set, target, untarget, and delete methods.


  • You can monitor JMS runtime objects using get methods.



For more information, see Navigating and Editing MBeans in the WebLogic Scripting Tool.





Listing 6-2 WLST Script to Modify JMS Objects




.
.
print '@@@ delete system resource'
jmsMySystemResource = delete("CapiQueue-jms","JMSSystemResource")
print '@@@ delete server'
jmsserver1mb = delete(jmsServerName,'JMSServer')
.
.
.






Best Practices when Using WLST to Configure JMS



This section provides best practices information when using WLST to configure JMS servers and resources:




  • Trap for Null MBean objects (such as servers, JMS servers, modules) before trying to manipulate the MBean object.


  • Use a meaningful name when providing a subdeployment name. For example, the subdeployment name DeployToJMSServer1 tells you that all subdeployments with this name are deployed to JMSServer1.


  • BEA provides sample scripts and utilities to configure WebLogic domain resources using WLST Offline and/or WLST Online. For more information, see the wlst Project Home.

Labels: