Transport Layer Security (TLS) and Web Service Connections in SaaS Integrations

A Checklist for Success with TLS Why We Need This Despite the full feature sets and capabilities that Oracle builds into their software-as-a-service (SaaS) cloud applications, there are still going to be occasional customers with business requirements that cannot be satisfied solely with a single SaaS subscription.  In these cases, it is possible to extend […]

OSB Http Transport Client Certificate Authentication Common Pitfall

I recently worked with a customer to help them resolve some issues they were having with configuring client certificate authentication (2-way SSL) for an Http Business Service in Oracle Service Bus (OSB).  This blog is to discuss a common issue encountered and how to fix it. The customer’s use case was to invoke a service […]

Using soapUI for secure, asynchronous web service invocations in Fusion Applications   

Using secure, asynchronous web services Fusion Applications exposes across all of its product families numerous web services that allows for querying, creating and updating of business objects. In this blog we will show how to leverage these services in a secure, asynchronous fashion from a web service client tool such as soapUI. While invoking services […]

Converting SSL certificate generated by a 3rd party to an Oracle Wallet

     
     Recently a customer asked me how to import his private key and certificate into an Oracle HTTP Server Wallet.
The customer generated a CSR outside the OHS Wallet Manager, using Open SSL, and sent it to a CA to get his certificates issued by them.
Unfortunately, the Wallet Manager only allows you to import certificates which were created for a CSR generated by the Wallet itself.
Despite this minor limitation, there is a workaround to get your private key, certificate and CA trusted certificates chain into Oracle Wallet.
This post explains the simple steps to achieve this, with a little help from Open SSL.

  1.       What you will need:
a. openssl installed in a machine
b. The server’s certificate (PEM format)
c. The server’s encrypted private key and it’s password
d. The CA root and intermediate certificates (these must be concatenated into a single file, also in PEM format)
 
        2.    On a server with openssl installed, issue the following command:
 

openssl pkcs12 -export -in certfile -inkey keyfile -certfile cacertfile -out ewallet.p12

 

Where:

                certfile: is the server’s certificate
                keyfile: is the server’s private key
                cacertfile: is the CA’s concatenated root and intermediate certificates.
 
Note that the resulting file must be named ewallet.p12 in order to be recognized by Oracle Wallet Manager.

 

 
3      3.       Enter the private key’s passphrase when prompted for it.
        4.       Enter an export password when prompted for it. You MUST supply a non-blank password. You will need to type it again as verification.
        5.       Upload the ewallet.p12 file to the Oracle Application Server. Move it to where the OHS can access it.
        6.       Start the Oracle Wallet Manager application.
        7.      Under the Wallet menu, click Open.
        8.      You will likely receive an error message about the default wallet directory not existing, and asking you if you want to continue. Click Yes.
 
 
       9.   You will be asked to select the directory where the wallet file is located. Find the directory where you moved the file ewallet.p12 to.
      10.   You will be asked for the wallet password. Enter the export password you entered when converting the certificate.
      11.   The wallet should open, and the certificate may be displayed as empty – don’t worry about that right now. You should also see the CA certificate under “Trusted Certificates”.
 
 
      12.   Under the Wallet menu, select “Auto Login”. Verify that it was selected by viewing the Wallet menu again; the Auto Login box should now have a check mark.
 
       13.  Under the Wallet menu, select “Exit” to quit the Oracle Wallet Manager application.
       14.   Now you should have 2 files in the directory: ewallet.p12 and cwallet.sso. Both files must be together at the same directory so the OHS can access the wallet.
       15.   Shutdown OHS.
       16.   Modify your OSH ssl.conf (default location should look something like /home/oracle/Middleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/ssl.conf) so the directive SSLWallet points to the directory where you saved both files, for example:
      
      SSLWallet “${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default
 

 17.   Start OHS and access its HTTPS home page. Inspect the certificate presented by the browser and you should see your new certificate and the CA chain.

 
 

 

OIM 11g R2 & X.509 authentication

OIM 11g R2 is out! This release brings a lot of new features and also improvements to existing features.OIM authentication providers are among the ones that were improved. The improvements make easier to integrate OIM with SSO solutions (for both SSO p…

Deploying OAM 11g Correctly Part 2 – Logins and SSL

This is another post in our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

A couple months ago Chris wrote a good post about the best way to deploy OAM from a web server / network architecture point of view.

Today, I’d like to touch on a very important but overlooked aspect of OAM deployments which is whether or not to use SSL between the web server and OAM. The product documentation and broader OAM writings out there in the community do a good job of describing the webgate to OAM server communication (OAP) security modes of open vs. simple vs. cert mode. However, what is completely neglected is the discussion of whether or not to use SSL between the web server and OAM.

This discussion applies to architectures where the OAM server is being fronted by a web server (usually OHS). This includes Fusion Apps deployments, the integrated IDM deployment described in the IDM Enterprise Deployment Guide (EDG), and many other custom deployments.

OAM 10g vs. 11g

In OAM 10g, users login by submitting credentials to the webate which then passes them along over the OAP protocol to the access server (OAM server equivalent in 10g). So, in 10g it was extra important to use simple mode or cert mode for the webgate to OAM communication if you don’t want credentials going over the wire.

In OAM 11g, users login by submitting credentials directly to the OAM server (running in WLS) which can be exposed directly to the user or put behind a web server (usually OHS). This means 2 things:

1) Credentials are no longer going over the webgate to OAM (OAP) connection. This somewhat lessons the value of using simple or cert mode; although username and response information that potentially carries confidential data still goes over this connection.

2) In the case where OHS is fronting OAM, user credentials are going from OHS to OAM/WLS. This means that if you don’t want those credentials to travel over the wire in the clear, that you should configure this connection to be over SSL.

Recommendation

If your security requirements and network are such that you want to encrypt credentials and other potentially confidential information going between the web server (OHS) and OAM, then you should configure the webgate to OAM communication to be simple or cert mode and configure the OHS to OAM/WLS communication to be SSL (HTTPS).

If your security requirements and network are such that you don’t care about encrypting credentials that go over the wire between the web server (OHS) and OAM then use open mode for the webgate communication and normal HTTP for OHS to OAM/WLS.

The following diagram illustrates both of these options.

I would argue it doesn’t make sense to do what many people do which is to use simple mode for webgate communication but normal HTTP without SSL for web server (OHS) to OAM/WLS communication.

How to deal with transport level security policy with OSB

OSB 11g PS4 consuming a Web service, that is secured by HTTP transport level security policy.

SSL offloading and WebLogic server redux – client x.509 certificates

I recently had to revisit the subject of SSL offloading and WebLogic server to include the ability to do client certificate authentication. I was specifically doing this for use with Oracle Access Manager 11g, but the configuration steps are identical …

Offloading SSL from WLS to the F5

Having trouble with your WebLogic Admin console?  Getting strange HTTPS or SSL messages from your browser when trying to save updates to the EM or Admin console?  So was I.  My browser presented me with the following warning, “Although this page is encrypted, the information you have entered is to be sent over an
unencrypted connection and could easily be read by a third party.  Are you sure you want to continue sending this information?” And, the WebLogic Server console did not save my changes. But, I was able to correct my configuration to resolve the issue.  So, I thought I would share my notes on the pieces involved.

In my case, there are three pieces involved:  F5, OHS (Oracle HTTP Server), and WLS (WebLogic Server 10.3.4).  SSL (or HTTPS) is terminated at the F5 (BIG-IP LTM) and HTTP traffic from the F5 to OHS is in plain-text.  OHS was necessary to support a third-party Single-Sign On (SSO) solution.

Starting with the F5, I needed to configure a header to be passed with the requests called WL-Proxy-SSL and set the value to true (WL-Proxy-SSL: true).  I found this well-documented in http://www.f5.com/pdf/deployment-guides/f5-weblogic10-dg.pdf in the section “Creating an HTTP profile”.  The F5 will set this header when it receives an HTTPS request bound for WebLogic Server. This lets WebLogic Server know that the original request was initiated over SSL.  This header should not be sent if the inbound traffic to the F5 was not SSL (HTTPS).

The second piece of the puzzle was the WebLogic plugin for OHS. The plug-in parameter documentation can be found here.  WLProxySSLPassThrough should be set to ON, so that the OHS proxy/plug-in will pass the WL-Proxy-SSL header on to WebLogic Server.
The parameter applies to each Location element and should look something like:

<Location /console>
    SetHandler weblogic-handler
    WebLogicHost MyHostName
    WeblogicPort 7001
    WLProxySSLPassThrough ON
</Location>

The next two changes are checkbox changes in the WebLogic Server console.  The first checkbox can be found on the WebLogic console under Preferences->Shared Preferences (banner at the top of the initial console splash page).  The field is called “Follow Configuration Changes” and is enabled by default.  This setting should be disabled so that the console does not trigger a reload of configuration pages when an activation of changes occurs.  Deselect the “Follow Configuration Changes” checkbox.

The final change was to configure the Adminserver so that it would acknowledge the proxy plugin headers.  This field is titled “WebLogic Plug-In Enabled” and can be found on the page Configuration->General in the Advanced section. This checkbox defaults to false, but should be changed to true when using the proxy plug-in.  Care should be taken when enabling this flag as it can open a potential security risk.  If this flag is enabled, the server should be secured so that client traffic can only come through your known proxy and not a rogue client masquerading as a proxy.  Additional details can be found in Chapter 11: Using WebLogic Security of Professional Oracle WebLogic Server.

5 minutes or less: User/Role API and SSL

This short post follows up Couple of things you need to know about the User/Role API. Now imagine that your LDAP identity provider is SSL enabled in 1-way mode (the server authenticates to the client, but the client does not authenticate to the server).

Now you need to tell Weblogic server how to validate the LDAP server certificate. And this is accomplished by adding the LDAP server CA certificate to the configured Weblogic trust store. If we’re talking about a self-signed certificate, simply add the certificate itself to the trust store. And there are a couple of options for the trust key store: Command Line, Custom Trust, Java Standard Trust or the OOTB Demo Trust. So far, so good. By adding the certificate to one of these options, Weblogic is all good to talk to the identity provider in SSL mode.

However, the User/Role API is not directly tied to Weblogic, so don’t expect it to take whatever is configured for the server. By default, as a standard Java-based client, the User/Role API looks for the standard Java $JDK_HOME/jre/lib/security/cacerts file, unless you tell it to look elsewhere, by informing the java system properties

javax.net.ssl.trustStore=<path_to_trust_store_file>
javax.net.ssl.trustStorePassword=<trust_store_password>

Relying on the original cacerts file may be dangerous in case you upgrade your JDK. If you need to leverage the existing certificates there, make a copy of the file and use the copy. Then simply tell the User/Role API where to read it from using the properties mentioned above.

Using the nsstools to manage SSL stores for curl

While working on today’s research project I also needed to test with curl. Sadly in my environment curl was built with NSS support which caused me some grief. I had never used NSS-enabled apps before and didn’t know how to deal with their certificate a…

SSL/TLS fun with client certificate authentication

Today’s adventure was a question about limiting SSL connections.

The customer’s problem statement was along the lines of

I want to make SSL connections, using client certificate auth (i.e. two-way ssl) and have the server accept only one certificate. Can I put the one cert I want in the “trusted CA list” to do that?

I thought the answer was “no, that’s not how you do that” but I wasn’t 100% sure so off I went on a research project…

I checked the relevant RFC (2246 for TLS) and found this in section 7.4.4 which talks about the server asking the client for a certificate:

certificate_authorities
A list of the distinguished names of acceptable certificate authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space.

I think that means that the cert the user uses has to be issued by one of the certificate authorities in that list, not that the cert is in that list. So I was pretty sure that the answer to their question was “no”, but I wanted to be absolutely sure, so that means testing.

First up – generating certificates. I used my dead simple CA script to generate the certificate for the host and another certificate I’ll use as the client certificate:


$ ./ca.sh ssltest.oracleateam.com
...
$ ./ca.sh tester
...

I had Apache and mod_ssl already installed (use yum to install mod_ssl and you’ll get both installed and configured).

Then I set Apache to use the ca’s certificate as the trust store and to demand a certificate from the client:


# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
SSLCACertificateFile /home/ec2-user/ca/ca.crt

...
SSLVerifyClient require

Then I tested with openssl directly and was able to connect without a problem:


[ec2-user@ssltest ~]$ openssl s_client -CAfile ~/ca/ca.crt -cert ~/ca/tester.crt -key ~/ca/tester.key -connect ssltest.oracleateam.com:443
CONNECTED(00000003)
depth=1 C = US, ST = Massachusetts, L = Boston, O = Oracle, OU = A-Team, CN = My Cert Authority, emailAddress = root@ssltest.oracleateam.com
verify return:1
depth=0 C = US, ST = Massachusetts, L = Boston, O = Oracle, OU = A-Team, CN = ssltest.oracleateam.com, emailAddress = root@ssltest.oracleateam.com
verify return:1
...
Acceptable client certificate CA names
/C=US/ST=Massachusetts/L=Boston/O=Oracle/OU=A-Team/CN=My Cert Authority/emailAddress=root@ssltest.oracleateam.com
...

Then I tried swapping the SSLCACertificateFile to just be “tester”‘s certificate:


SSLCACertificateFile /home/ec2-user/ca/tester.crt

and ran the same command again:


[ec2-user@ssltest ~]$ openssl s_client -CAfile ~/ca/ca.crt -cert ~/ca/tester.crt -key ~/ca/tester.key -connect ssltest.oracleateam.com:443
CONNECTED(00000003)
depth=1 C = US, ST = Massachusetts, L = Boston, O = Oracle, OU = A-Team, CN = My Cert Authority, emailAddress = root@ssltest.oracleateam.com
verify return:1
depth=0 C = US, ST = Massachusetts, L = Boston, O = Oracle, OU = A-Team, CN = ssltest.oracleateam.com, emailAddress = root@ssltest.oracleateam.com
verify return:1
3079509740:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1193:SSL alert number 48
3079509740:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
...
Acceptable client certificate CA names /C=US/ST=Massachusetts/L=Boston/O=Oracle/OU=A-Team/CN=tester/emailAddress=root@ssltest.oracleateam.com

and the openssl client dropped the connection.

So openssl either doesn’t know what to do when the “Acceptable client certificate CA names” matches the certificate or that’s simply not allowed.

I also tested with a little perl script:


#!/usr/bin/perl

use LWP::UserAgent;

$HOME=$ENV{HOME};

$ENV{HTTPS_CA_FILE} = "$HOME/ca/ca.crt";
$ENV{HTTPS_DEBUG} = 1;

$ENV{HTTPS_PKCS12_FILE} = "$HOME/ca/tester.p12";
$ENV{HTTPS_PKCS12_PASSWORD} = 'ABcd1234';

$ua = LWP::UserAgent->new(ssl_opts => { verify_hostname => 1 });
$response = $ua->get("https://ssltest.oracleateam.com/");

if ($response->is_success) {
print $response->content;
}
else {
print STDERR $response->status_line, "\n";
}

So how are you supposed to do that?

If you’re using Apache then you just configure Apache to accept only the one certificate you want. This from the sample httpd.conf (actually ssl.conf, but that’s included in httpd.conf):


# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#

Updated dead simple certificate authority

Back in April I posted a shell script I wrote to implement a dead simple Certificate Authority for testing purposes. I recently revisited that script because I needed JKS files in addition to the PEM format files it created.

Without further ado my new and improved script is available right after the break.

#!/bin/bash

# a very simple cert authority
# now with JKS support!
#
# Copyright 2011 Oracle
# christopher.johnson@oracle.com
#

# License agreement:
# ------------------
# This script is intended as a simple sample and/or for my own
# purposes. If you get any benefit from it then that's GREAT but there
# are NO warranties and NO support. If this script burns down your
# house, chases your dog away, kills your houseplants and spoils your
# milk please don't say I didn't warn you.


# You should probably use a better passphrase than this
PASSPHRASE=ABcd1234

baseAnswers() {
echo US
echo Massachusetts
echo Boston
echo Oracle
echo A-Team
echo $1
echo root@`hostname`
}

answers() {
baseAnswers $1
echo ''
echo ''
}

# No need to edit past here

createderfiles() {
echo Creating .der files for $1

openssl pkcs8 -topk8 -nocrypt -in $1.key -inform PEM -out $1.key.der -outform DER
openssl x509 -in $1.crt -inform PEM -out $1.crt.der -outform DER
}


# better safe than sorry
umask 077

# these next two lines figure out where the script is on disk
SCRIPTPATH=`readlink -f $0`
SCRIPTDIR=`dirname $0`

# find keytool in our path
KEYTOOL=`which keytool`
if [ "$KEYTOOL" == "" ] ; then
echo "keytool command not found. Update your path if you want this"
echo "tool to create JKS files as well as PEM format files"
fi

# if you're running this from somewhere else...
if [ $SCRIPTDIR != "." -a $SCRIPTDIR != $PWD ]; then
# then CD to that directory
cd $SCRIPTDIR
if [ "$KEYTOOL" == "" ]; then
echo "Output files (.crt, .key) will be placed in $PWD"
else
echo "Output files (.crt, .key, .der and .jks) will be placed in $PWD"
fi
fi

if [ ! -e ca.crt -o ! -e ca.key ]; then
rm -f ca.crt ca.key ca.p12
echo "Creating cert authority key & certificate"
baseAnswers "My Cert Authority" | openssl req -newkey rsa:1024 -keyout ca.key -nodes -x509 -days 365 -out ca.crt 2> /dev/null
fi

if [ "$KEYTOOL" != "" ] ; then
if [ ! -e ca.crt.der -o ! -e ca.key.der -o ! -e ca.jks ]; then
# convert to der
createderfiles ca

# we actually don't need/want the ca.key.der but there's no
# harm in leaving it around since the .key file is here anyway

echo "Creating ca.jks"
# import the CA certificate into the JKS file marking it as trusted
keytool -import -noprompt -trustcacerts \
-alias ca \
-file ca.crt.der \
-keystore ca.jks \
-storetype JKS \
-storepass $PASSPHRASE \
2> /dev/null
fi
fi

if [ $# -eq 0 ] ; then
echo "This script creates one or more certificates."
echo "Provide one or more certificate CNs on the command line."
echo "Usage: `basename $0` <certcn> [certcn [...]]"
exit -1
fi

for certCN in $@ ; do
echo Certificate for CN \"$certCN\"
echo =============================================

KEY=$certCN.key
CRT=$certCN.crt
REQ=$certCN.req
P12=$certCN.p12
JKS=$certCN.jks

# files we can delete later
KEYDER=$KEY.der
CRTDER=$CRT.der

ABORT=0
if [ -e $KEY ] ; then
echo " ERROR: Key file $KEY already exists"
ABORT=1
fi
if [ -e $REQ ] ; then
echo " ERROR: Request file $REQ already exists"
ABORT=1
fi
if [ -e $CRT ] ; then
echo " ERROR: Certificate file $CRT already exists"
ABORT=1
fi

if [ $ABORT -eq 1 ] ; then
echo ''
echo "If you wish to recreate a certificate for you must delete"
echo "any preexisting files for that CN before running this script."
echo ''
echo ''
else
answers $certCN | openssl req -newkey rsa:1024 -keyout $KEY -nodes -days 365 -out $REQ 2> /dev/null

# at this point we have a key file, but the cert is not signed by the CA
openssl x509 -req -in $REQ -out $CRT -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.serial -days 365 2> /dev/null

# We now have a req, key and crt files which contain PEM format
# x.509 certificate request
# x.509 private key
# x.509 certificate
# respectively.

echo "Certificate created."
ls -l $KEY $REQ $CRT

echo 'Certificate information:'
openssl x509 -in $CRT -noout -issuer -subject -serial

# generate a pkcs12 file
openssl pkcs12 -export -in $CRT -inkey $KEY -certfile ca.crt -name $certCN -out $P12 -password pass:$PASSPHRASE -nodes

echo P12 info:
ls -l $P12
#openssl pkcs12 -in $P12 -info -password pass:$PASSPHRASE -passin pass:$PASSPHRASE -nodes

# if we have keytool we also need to create a jks file
if [ "$KEYTOOL" != "" ] ; then
echo "Will create JKS file as well..."
createderfiles $certCN

echo "Creating $JKS"
# step 1: copy the CA keystore into the new one
cp ca.jks $JKS

# step 2: take the pkcs12 file and import it right into a JKS
keytool -importkeystore \
-deststorepass $PASSPHRASE \
-destkeypass $PASSPHRASE \
-destkeystore $JKS \
-srckeystore $P12 \
-srcstoretype PKCS12 \
-srcstorepass $PASSPHRASE \
-alias $certCN

ls -l $JKS

keytool -list -keystore $JKS -storepass $PASSPHRASE
fi

fi

done

To use just make a new directory and put the above into a script in that directory. I usually mkdir ~oracle/simpleca and put the script in ca.sh. Then just run ca.sh.

Enjoy!

SSL offloading and WebLogic server

A couple of weeks ago I wrote about using Apache to simulate an SSL load balancer and showed this diagram: One of the important things to note is that by default in this architecture WebLogic and any J2EE applications won’t know that the user is usin…

Using Apache to simulate an SSL Load balancer

Last week I needed to duplicate a customer’s OAM 11g environment to help understand and resolve a problem they were having and needed to simulate a config that looks like this: The numbers indicate the TCP port used on the server side. All of the red l…

A dead simple certificate authority for testing purposes

I don’t know about you, but I know I’d rather spend an hour writing a script to automate something than 30 minutes figuring out how to use an existing but annoying/terrible tool. I do that not because I am a glutton for punishment, but because I know I’ll have to use that terrible tool again in the future and I won’t remember how to use it anyway.

So when I needed certificates for a test environment I checked out OpenSSL’s built in CA tool, quickly decided against using it, and then wrote my own simpler tool.

Enjoy!

Update: There’s a new version of this script available in a new post

To use:

  1. make a directory to contain the script and the keys and certs it will generate
  2. copy/paste this code into a file in that directory. I called it make-cert, but use whatever name you like
  3. run it

The script takes one or more parameters that specify the CN of the cert you want it to generate. So


$ ./make-cert myserver.mydomain.com

will make a cert for myserver.mydomain.com. It will also take more than one CN on the command line, so


$ ./make-cert myserver.mydomain.com login.mydomain.com

will make a certificate for myserver.mydomain.com and another one for login.mydomain.com.

NOTE: There’s a new version of this script available in a new post

And here’s the code



#!/bin/bash

# a very, very simple cert authority
#
# Copyright 2011 Oracle
# christopher.johnson@oracle.com
#

# License agreement:
# ------------------
# This script is intended as a simple sample and/or for my own
# purposes. If you get any benefit from it then that's GREAT but
# there are NO warranties and NO support. If this script burns down
# your house, chases your dog away and spoils your milk please don't
# come crying to me.


baseAnswers() {
echo US
echo Massachusetts
echo Boston
echo Oracle
echo A-Team
echo $1
echo root@`hostname`
}

answers() {
baseAnswers $1
echo ''
echo ''
}


# better safe than sorry
umask 077

# these next two lines figure out where the script is on disk
SCRIPTPATH=`readlink -f $0`
SCRIPTDIR=`dirname $0`

# if you're running this from somewhere else...
if [ $SCRIPTDIR != "." -a $SCRIPTDIR != $PWD ]; then
# then CD to that directory
cd $SCRIPTDIR
echo "Certificate and key files (.crt and .key) will be placed in $PWD"
fi


if [ ! -e ca.crt -o ! -e ca.key ]; then
echo "Creating cert authority key & certificate"
baseAnswers "My Cert Authority" | openssl req -newkey rsa:1024 -keyout ca.key -nodes -x509 -days 365 -out ca.crt 2> /dev/null
fi


if [ $# -eq 0 ] ; then
echo "This script creates one or more certificates."
echo "Provide one or more certificate CNs on the command line."
echo "Usage: `basename $0` [certcn [...]]"
exit -1
fi

for certCN in $@ ; do
echo Certificate for CN \"$certCN\"
echo =============================================

KEY=$certCN.key
CRT=$certCN.crt
REQ=$certCN.req

ABORT=0
if [ -e $KEY ] ; then
echo " ERROR: Key file $KEY already exists"
ABORT=1
fi
if [ -e $REQ ] ; then
echo " ERROR: Request file $REQ already exists"
ABORT=1
fi
if [ -e $CRT ] ; then
echo " ERROR: Certificate file $CRT already exists"
ABORT=1
fi

if [ $ABORT -eq 1 ] ; then
echo ''
echo "If you wish to recreate a certificate for you must delete"
echo "any preexisting files for that CN before running this script."
echo ''
echo ''
else
answers $certCN | openssl req -newkey rsa:1024 -keyout $KEY -nodes -days 365 -out $REQ 2> /dev/null

# at this point we have a key file, but the cert is not signed by the CA
openssl x509 -req -in $REQ -out $CRT -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.serial 2> /dev/null

echo "Certificate created."
ls -l $KEY $REQ $CRT

echo 'Certificate information:'
openssl x509 -in $CRT -noout -issuer -subject -serial
fi

done

Note: an earlier version of this script was missing a $1 in the answers() function. The above script contains the correction.

OAM 11g Connecting to an LDAP ID store over SSL (LDAPS)

Connecting to an LDAP ID store in OAM 11g over SSL (LDAPS) is a common scenario that many customers may need to implement. Unfortunately the documentation on this subject is scant and can be misleading. So as part of the OAM 11g Academy series, I’d l…

T3S -T3 over SSL

T3 is the protocol used for RMI communication with WebLogic server. T3S is the version of the protocol over SSL when secure communication is required.

I was going to write up a post about doing T3 over SSL as it seems to be something that people get hung up on.

However, Markus Eisele seems to have beaten me to it with an excellent and fairly comprehensive post.

I’d just like to add:

When you import the trusted CA into the default JVM cacert store make sure it is on the CLIENT JVM (and as the blog points out the correct JVM).

Also, rather than importing the trusted CA into the default JVM cacert store, you can create your own keystore and specify to the client SSL stack to use that store instead.

If you are using a standard J2SE stack for the client then you do this by starting the client with the following flags:

-Djavax.net.ssl.trustStore=**trustStore file path**
-Djavax.net.ssl.trustStorePassword=**trustStorePassword**

However, if you are using the WLS stack for the client you would do this with these flags:

-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=**trust store file path**
-Dweblogic.security.CustomTrustKeyStorePassPhrase=**keystore pass phrase**