Fusion Middleware and Certificate Expirations

I wanted to take a moment to blog about one of the most common, yet most easily preventable causes of middleware system outages. The cause is the expiration of digital certificates used in middleware infrastructure.

Certificates are used throughout many Oracle Fusion Middleware products for purposes of authentication and encryption. This includes:

• Server certificates for SSL in OHS and WLS
• Certificates used for intra and inter product transport communication in WLS, OAM, OAAM, OID, OVD, OIM, OSB etc…
• Certificates used for signing and authentication in OWSM, WLS, OSB, OIF, and Oracle STS.

Despite the fact that digital certificates are such an integral part of middleware infrastructure, you might be surprised how many customers are not well organized about their PKI and in particular about when the different certificates in their infrastructure expire.

It is such a little, simple thing, but all it takes is one expired certificate in one middleware component to bring an application down.

I encourage you today to “not be that customer”, stay organized and keep track of when your certificates expire so that you can issue updated certificates before that happens.

A Note about OAM and the certificates used in Simple Mode

OAM has three different security “modes” for the communication done between the webgate (web server plug-in) and the OAM server component which processes authentication and authorization. These 3 modes are:

• Open: Unencrypted communication
• Simple: Communication over SSL using certificates generated by OAM using an Oracle CA certificate that comes with OAM. Simple mode is popular with customers who want to secure webgate to OAM server communication but don’t feel the need to use their own PKI infrastructure.
• Cert: Communication over SSL using certificates issued by a third party CA.

The mode most relevant to this discussion on expiring certificates is simple mode where the certificates are generated automatically and may be out of sight and mind.

In OAM 10g the certificates are only issued with a validity period of one year by default. If you want to extend the validity period for the certificates generated in simple mode (and I recommend that you do), then follow the instructions in appendix F, section 2.9 of the OAM Identity Admin Guide: http://download.oracle.com/docs/cd/E12530_01/oam.1014/b32419/trblsht.htm#BABDDBJF

In OAM 11g, the validity period of the certificates used in simple mode is 10 years, making early expiration of the certificates less of a problem.

JAVA Key Stores for SOA Security

In a how-to post on SAML OWSM client policies last month, Josh mentioned how he used separate “Alice and Bob” keystores for the client and the service. I think this is a very important notion and would like to expound upon it in this post.

I see too many people building out SOA development and test environments that utilize a single key store for all the components in their environment. Even worse, I see lots of people utilizing the same key and certificate pair for every component in their environment. If your environment is a dev/test environment built on Oracle products, this is likely the ever-popular “orakey” pair.

I believe that it is important to utilize separate keystores and key-certificate pairs for the client, service, and any intermediary components where keys and certificates are required in your development and test environments.

Taking the short cut of having components share keystores and even key-certificate pairs will only burn you down the road as you move forward with the development of your services and applications. Sharing keys and keystores can mask potential issues that will appear when you try to setup real keystores as you approach production. Further, sharing keys and keystores can actually make it more difficult to diagnose and solve certain issues that can occur during the build out and configuration of an environment.

I will now walk you though the simple steps of creating properly configured client “Alice” and service “Bob” keystores using the Oracle CertGen and ImportPrivateKey utilities. Following these steps you can have proper test keystores ready to go in a matter of minutes.

1) Create client (Alice) key-certificate pair signed by the demo CA cert "CertGenCA"

>> java utils.CertGen -certfile AliceCert -keyfile AliceKey -keyfilepass password

2) Create service (Bob) key-certificate pair signed by the demo CA cert "CertGenCA"

>> java utils.CertGen -certfile BobCert -keyfile BobKey -keyfilepass password

3) Create client (Alice) keystore with client key-certificate pair

>> java utils.ImportPrivateKey -certfile AliceCert.der -keyfile AliceKey.der -keyfilepass password -keystore Alice.jks -storepass password -alias alice -keypass password

4) Create service (Bob) keystore with client key-certificate pair

>> java utils.ImportPrivateKey -certfile BobCert.der -keyfile BobKey.der -keyfilepass password -keystore bob.jks -storepass password -alias bob -keypass password

5) Now add the root CA to both stores

>> keytool -importcert -file CertGenCA.der -keystore Alice.jks

>> keytool -importcert -file CertGenCA.der -keystore bob.jks

6) Add bob's public cert to Alice's store. This is needed to configure the recipient alias on the client

>> keytool -importcert -file BobCert.der -alias bob -keystore Alice.jks

7) Use and prosper!