OPSS Keystore Service - centralised key management
31 Mar 2015 by Simon Haslam (in General)
This is a topic I've been meaning to write about for a while: FMW Infrastructure 12.1.2 introduced a rather nice OPSS Keystore Service (KSS) which is now used by default in SOA Suite 12.1.3 (and other 12c products soon no doubt).
As most readers will know WebLogic, and therefore the layered products that sit on top of it like SOA or WebCenter, uses Java Keystore files (.jks) to store server identity certificates and trust certificates/key-chains (before JKS people used flat files).
If you're building clusters you want to centralise configuration where possible to keep things simple - that's why it's nice to put things like the server memory parameters in the domain configuration. Unfortunately you still had to distribute (and later update) JKS files to each host... until KSS arrived.
What the Keystore Service does is to provide keystores to WebLogic server instances - at run-time from from a central place (the OPSS schema in the Fusion Middleware infrastructure repository).
Managing the Keystores
You can manually manage the keystores using EM Fusion Middleware Control, via the Security menu on the domain. By default you will have demo trust and demo identity keystores, for example created by the Configuration Wizard, but you can create your own and delete the demo ones. See the documentation at: https://docs.oracle.com/middleware/1213/idm/app-security/kssadm.htm.
In practice you'll probably want to use WLST - KSS has a set of commands for manipulation keystores, like this:
importKeyStore(appStripe='stripe', name='keystore', password='password', aliases='comma-separated-aliases', keypasswords='comma-separated-keypasswords', type='keystore-type', permission=true|false, filepath='absolute_file_path')
See https://docs.oracle.com/middleware/1213/idm/wlst-reference/custom_infra_security.htm#IDMCR11439 for the WLST KSS reference.
Configuring the Server
When you configure the domain you simply specify a keystore type of "kss" and where you would previously have specified a full path to a JKS file, you now enter a URI of the form kss://<stripe>/<name>
Then in the WebLogic instance log you get the normal identity and trust messages, just referencing this new type of keystore, e.g.
<BEA-090169> <Loading trusted certificates from the kss keystore file kss://system/trust.>
Of course this does put a dependency on the database to even start up WebLogic (or else you get the failed to open identity store error), but for SOA etc, that would be expected anyway.
Hostname Verifier Change
One other snippet you shouldn't really be interested in... Oracle have changed the default hostname verifier such that if the presented certificate's common name (CN) is "DemoCertFor_<your-domain>" it will be accepted as valid if you trust demo certificates. In other words, you can use the same demo identity certificate for any server in your domain, and any other server trusting demo certs will be accept it. This makes configuring SSL with demo certs and hostname verification enabled (or not - pah!) slightly simpler. The demoidentity passwords are the same as in previous versions, i.e. DemoIdentityKeyStorePassPhrase and DemoIdentityPassPhrase.
This is a good point to remember what Oracle's WebLogic Security Architect, Will Hopkins, says:
Please don't use Demo Certificates in production environments since it makes your system less secure. And the T-shirt that the "best dressed" WebLogic geeks were wearing at UKOUG Tech14 was:
In summary then, the relatively new OPSS Keystore Service provides a very appealing centralised method to manage your WebLogic keys and certificates. It will helpful to administrators with clustered, and particularly those with large, Fusion Middleware 12c estates.