Self-signed Certificate & Java Security Warning & Browser

dev setup:

• html page XYZ hosting Java Applet ABC
• Java Applet ABC signed by mykey
• mykey - self-issued pivate key

security warning - untrusted applet signer

When loading html page, we got security warning as below:

Reason:  The applet is signed using self-issued key (for dev only)

To resolve:

Export signer pubkey certificate (its private key is used to sign applet ABC)

C:\> keytool -export -keystore c:\Users\*****\.keystore -alias mykey -file C:\Users\*****\workspace\POC\jwangdev.cer.p12

Enter keystore password: dev1234

Import singer certificate into “Signer CA” via Java Control Panel.

Java Control Panel -> Security -> Manage Cerficates… -> choose “Signer CA” -> import C:\Users\*****\workspace\POC\jwangdev.cer.p12

restart browser. done.

applet security warning - untrusted https certificate issuer

reason:
From the signed applet ABC, we have https connection to https://localhost:8443 (a dev jboss server with default self-signed https certificate for "localhost"). When applet tries to make such https connection, we have security warning window as below: 

To suppress the above warning window:

Add “C:\Users\*****\workspace\POC\ dev_jboss_cert.cer.p12” certificate to “Secure Site” via Java Control Panel. 

restart browser. done.

weblogic integrating remote ejb via foreign jndi provider

Server Env Overview

weblogic 12c (12.1.1), with domain setup as

• AdminServer - domain admin 
• CoreServer - host core business service EJBs
• AppServer - host application specific EJBs which uses core business service EJBs

Foreign JNDI Provider Setup

login to admin console -> domain -> Services -> Foreign JNDI Providers, create new Foreign JNDI Provider

where Provider URL is pointing to CoreServer and Targets points to AppServer.

Add Foreign JNDI Links as

where Local JNDI Name is the global JNDI name used in EJBs from AppServer and Remote JNDI Name is the global JNDI name for remote EJBs deployed in CoreServer.

Inject Remote EJBs via @EJB annotation

To use remote ejbs from JavaEE components from AppServer (say EJBs), simply add EJB ref as

@EJB(mappedName="<the_local_JNDI_name_as_defined_in_Foreign_JNDI_Links>") 
AssignmentEjb tmpEjb;

where mappedName is the global JNDI name as defined in local JNDI name in Foreign JNDI Links in Weblogic Admin console.

eclipse remote debugging app in managed weblogic server

Dev Env Overview

• Eclipse JUNO + OEPE bundle
• WLS 12c (12.1.1) in remote Linux
• domain setup: admin server, core server, front server, app server

Launch managed WLS server in development mode with debug on

1. cd $WLS_DOMAIN/bin
2. start Admin server: startWebLogic.sh << WLS Start Mode=Development
3. start managed CoreServer0: startManagedWebLogic.sh CoreServer0
4. start managed FrontServer: startManagedWebLogic.sh FrontServer
5. start managed AppServer in dev mode with debug on

debugFlag=true DEBUG_PORT=29898 startManagedWebLogic.sh MyAppServer t3://<my-app-server-host>:<my-app-server-port> noderby

Eclipse Setup

1. download/install Eclipse JUNO + OEPE bundle from Oracle website
2. configure proxy
   
3. install m2e plugin for Juno "M2E - Maven Integration for Eclipse" from Eclipse Marketplace
   
4. in Java EE perspective, in Servers tab, create a new server pointing to remote Linux server
   
   22426: my wls domain admin port; 29898: my appserver debugging port
5. update advanced publishing config of the newly added server (change designed target server)
   
6. (checkpoint) now Eclipse is talking to remote server
7. add Java EE project to new server

Publish Dev Change to Remote Server

1. make dev changes
2. when you're ready, click the publish icon () to publish to remote server to testing 

Debugging App on Remote Server

1. (checkpoint) make sure remote Server is running with debug On
2. from Eclipse -> Java EE Perspective -> Servers view, click debug icon () to enter debug mode
3. set breakpoint in IDE
4. hit the server; Eclipse will bring up debug perspective when breakpoint is reached
   
   

WLS 12c to JBOSS 7.1.1.Final JMS Bridging Setup

Configuration

• WLS 12c (WLS Queue, WLS JMS Bridge)
• JBoss 7.1.1.Final (JBOSS Queue)

Steps on JBOSS AS 7.1.1.Final

Create JMS Queue on JBOSS

Edit standalone-full.xml, add queue configuration as

<hornetq-server>
<jms-destinations>
<jms-queue name="VSSQueue">
<entry name="queue/VSS"/>
<entry name="java:jboss/exported/jms/queue/VSS"/>
</jms-queue>
</jms-destinations>
</hornetq-server>

Start JBOSS With Fully Qualified Domain Name (FQDN)

Starting with FQDN allows the connection of WLS bridge originated from yet another host

$ cd $JBOSS_HOME
$ export JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=jboss_host.company.com"
$ export JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address.management=jboss_host.company.com"
$ bin/standalone.sh -c standalone-full.xml



Steps on WLS 12c

Copy JBOSS JMS libs to <WLS_DOMAIN>/lib

To make WLS talk to JBOSS via JMS, we need to add

• hornetq-jms-client.jar (from hornetq-2.2.14.Final/lib) and 
• jboss-client.jar  (from $JBOSS_HOME/bin/client) 

to <WLS_DOMAIN>/lib (Note: JBOSS AS7.1.1.Final uses hornetq-2.2.13, but works with 2.2.14)

Deploy resource adapters jms-notran-adp/jms-xa-adp to WLS

To use JMS bridging, we need to deploy jms-notran-adp/jms-xa-adp to WLS as

1. Click Deployments (LHS) > Lock & Edit > click install (RHS) > select /<USER>/Development/Env/wls1211_dev/wlserver/server/lib/jms-xa-adp.rar > choose Install this deployment as an application > select desired target server -> Finish
2. Click Deployments (LHS) > check jms-xa-adp > click Start Serving all requests > State should be "Active" 

Create JMS System Module

Login to WLS console > (LHS) Services > Messaging > JMS Modules > (RHS) new JMS Modules (System)  > select target server -> Finish

Create JMS Server

in WLS console, (LHS) Services > Messaging > JMS Servers > (RHS) click New > enter Name > create and select persistent store > select target server > Finish

Create Subdeployment

in WLS console,  (LHS) Services > Messaging > JMS Modules > (RHS) select JMS module we just created > click Subdeployments tab > click New > enter Subdeployment Name > select target JMS server > Finish

Create JMS Queue and ConnectionFactory

	Name	Type	JNDI Name	Subdeployment	Targets
	MyConnectionFactory	Connection Factory	jms/QCF	Default Targetting	myserver
	MyTestQueue	Queue	jms/TestQ	MyTestQueueSubDeploy	MyJMSServer

create/select subdeployment and target server

Create JMS Bridge

create source destination: queue@WLS
create target destination: queue@JBOSS
create JMS bridge

Restart WLS 

Ref:

GIT Submodules Recipes

In Git, parent project is associated with submodule project at git-commit level, NOT at git-branch level.

ParentProj at GIT-repo-Parent
ChildProj at GIT-repo-Child

Person GitAdmin setup git repo

• parentRepo
• childRepo

PersonA clone and add submodule

• personA clone parentProj 
• personA clone childProj
• personA add childProj  to parentProj as submodule
• personA commit submodule change (at commit 100)
• personA push up changes 

PersonB use parentProj

• personB clone parentProj (including childProj)
• personB init, update submodule childProj (now childProj is at detached commit 100) 

PersonA upgrades submodule

• personA update childProj in master
• personA commit changes in childProj in master (at commit 120)
• personA push up childProj changes to origin/master

PersonA update parent to use childProj's newest commits

• personA add/commit childProj changes in parentProj (uses new childProj commit 120)
• personA push up parentProj  

PersonB updates parentProj to pick up changes

• PersonB pull parentProj changes (will see parentProj points to a newer ChildProj commit 120)
• PersonB update submodule (this will sync ChildProj to the commit 120) notes: will lost local uncommitted changes in ChildProj

Android: launch app via URI link from web browser

Android: steps for launch app via URI link from web browser

edit launcher.html
..
<a href="myscheme://?host=my_app_server&port=9000&servername=StubServer">MyApp@MyServer</a>
..

Android project:
edit AndroidManifest.xml, add activity's intent-filter as below:

<application android:icon="@drawable/ventyx_icon" android:label="@string/app_name"

        android:debuggable="true" android:logo="@drawable/splash">

 <activity android:name="MyMobile" android:label="@string/app_name" ....>

     <intent-filter>

<action android:name="android.intent.action.VIEW" />

<category android:name="android.intent.category.DEFAULT" />

<category android:name="android.intent.category.BROWSABLE" />

<data android:scheme="myscheme" />   << all lowercase

     </intent-filter>           

  </activity>

....

The above code will launch "MyMobile" application if the scheme is myscheme, e.g., "myscheme://"

For better control the launcher URL, we can apply more intent filter options as 

<data android:scheme="myscheme" android:host="myapp.dev.com" android:pathPrefix="/mobile" />
In this case, MyMobile application will be launched by URL like below:
<a href="myscheme://myapp.dev.com/mobile?other_query_params">

Even though server's self-signed SSL certificate has been imported and trusted, but iPad won't start SSL connection due to CN doesn't match hostname.

Confirmed:

Even though server's self-signed SSL certificate has been imported and trusted, but iPad won't start SSL connection due to CN doesn't match hostname.

Application Setup:

• WLS Server configured with self-signed SSL certificate (whose CN=my_company_name doesn't match its DNS name, appserver.mydomain.com)
• Application (java) deployed on WLS
• Mobile Application (phonegapped) on mobile devices (iPad, Android) 

Verification Goal:

• Can mobile application from device communicate with App services via HTTPS in the above settings?

Verification Steps:

1. import WLS's self-signed SSL certificate into iPad as trusted certificate
2. launching mobile app to hit server via https
3. Even though server's self-signed SSL certificate has been imported and trusted, but iOS won't start SSL connection due to CN doesn't match hostname.

** test output 

Aug 22 10:20:42 Dev-iPad-699600 amfid[179] <Error>: Aug 22 10:20:42  SecTrustEvaluate  [leaf CriticalExtensions IssuerCommonName]

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: mobile launchOptions = ….. protocol=https

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: Multi-tasking -> Device: YES, App: YES

Aug 22 10:20:43 Dev-iPad-699600 kernel[0] <Debug>: launchd[178] Builtin profile: container (sandbox)

Aug 22 10:20:43 Dev-iPad-699600 kernel[0] <Debug>: launchd[178] Container: /private/var/mobile/Applications/5E78D4F8-B359-4F99-905C-D09B00E88605 (sandbox)

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: Resetting plugins due to page load.

Aug 22 10:20:43 Dev-iPad-699600 webinspectord[140] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: Finished load of: file:///var/mobile/Applications/5E78D4F8-B359-4F99-905C-D09B00E88605/mobile.app/www/index.html

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: Resetting plugins due to page load.

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Error>: Aug 22 10:20:43  SecTrustEvaluate  [leaf SSLHostname]

Aug 22 10:20:43 Dev-iPad-699600 mobile[178] <Warning>: Failed to load webpage with error: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “appserver.dev.mydomain.com” which could put your confidential information at risk.

** end