Ace

Replacing an expired identity certificate in a JKS based keystore is pretty easy stuff, unless you have forgot to keep a backup of your private key. This post discusses the use-case where we don't have a backup copy of the private key outside the JKS keystore, and we wish to replace the expired/going-to-expire identity certificate There are two ways that I know of: Portecle (easy) - this is a tool available out on internet OpenSSL-Keytool combination (lengthy one) I will discuss 2nd one, and would only provide commands (and not discuss each switch as you can always refer relevant product docs for it) 1. Backup the JKS keystore, suppose original is  "keystore.jks" 2. JKS -> PKCS12 conversion (pkcs12 obtained in this step would be run through OpenSSL in next step, to separate the private key from the expired certificates)          keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS

This post is about dynamically enabling (or disabling) the  JDBC driver level logging with debug version of Oracle JDBC thin driver "ojdbc6_g.jar" in place while app server is up and running. Typically, when this jar is put in place in application server environment, we enable the logging using JAVA system property "-Doracle.jdbc.Trace=true". This approach is static in the sense that application server restart is needed each time we want to enable or disable the logging. This static approach is not at all feasible in a production system where we want to trace the jdbc calls at some particular instance of time. A programmatic (dynamic) approach to enable/disable driver level logging is also discussed in doc "http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm". However this approach is suitable for enabling/disabling the logging from within the application. So this method would essentially only trace JDBC calls at places where application

Configuring SCAN and ONS on WLS GridLink datasource is already covered in Oracle whitepaper here In this discussion today, I will list high level steps that are needed to configure secure SCAN and secure ONS on WLS GridLink Datasource instead of using their plain counterparts. Here are the high level steps: 1) TCPS based listener configuration needs to be implemented on DB server side. Once it is done, we would get a secure SCAN URL. Based on this scan URL, we would get jdbc URL for use with our GridLink datasource, something like: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=sup.oracle.vm)(PORT=1523)))(CONNECT_DATA=(SERVICE_NAME=racdb.oracle.vm))) 2) ONS daemons running on RAC nodes need to be secured as well with user certificate (using wallet). Note that it is essential to have ditto wallet configuration in following(or equivalent) files to secure ONS daemon successfully: node1: ons.config ons.config.node1 node2: ons.config ons.config.node2 Here is sa

WebLogic provides many ways to automate lifecycle of cluster members to achieve server/service high availability without affecting service quality. For instance, we can configure whole server migration to make sure that in an event of physical  machine failure cluster members hosted on that machine are started on another machine. There are alternative methods to manage server (or process migration, at OS level), or simply, to control the lifecycle activity of  a process. These alternative methods include inbuilt (or packaged) clustering software that comes with various flavors of Linux/Unix. This post discusses the possible way to make such clustering software control WebLogic instances. The central thing about this is the use of W eb L ogic S cripting T ool ( or WLST) script. This WLST script file would be invoked from service script (which is just a specific form of shell script used to execute lifecycle activities of a process) with appropriate argument, like start, stop, st

JAVA 1.6 HTTP client's inherits support for SPNEGO via Java GSS. This is listed at:     http://docs.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html From WebLogic side, the answer(to the question why JAVA HTTP client only works with certianin versions) lies in simple test that is carried out using "supported" browser and JAVA fat client against same version of WebLogic and then analyzing the network dumps. Network dumps show: For JAVA fat client(not working against WebLogic 10.3.3) GSS-API Generic Security Service Application Program Interface               OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)               Simple Protected Negotiation                               negTokenInit                                               mechTypes: 1 item                                                  MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) For browser (working  against WebLogic 10.3.3) GSS-API Generic Securit

In IdP initiated SSO, you might have a jsp/html resource at IdP end where SP services are defined having  similar form snippet: <input type="hidden" name="SPName" value="<%=spname%>" <input type="hidden" name="RequestURL" value="<%=requestURL%>" <input type="hidden" name="param1" value="<%=value1%>" <input type="hidden" name="param2" value="<%=value2%>" <input type="hidden" name="param3" value="<%=value3%>" However you are getting following exception whenever SP service is invoked from above jsp/html: ####<Sep 29, 2011 2:01:14 PM IST> <Debug> <SecuritySAML2Service> <MyMac> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1311113162898>