September 9 2014

When working with a colleague on a sample SOA 12c project recently I noticed a change in 12c that I had not seen mentioned anywhere yet.  In the sample project we were integrating with the Atlassian OnDemand service in order to provision users for Confluence and JIRA.  The integration is performed using a SOAP service over SSL.  In this situation, like at many of our customers, we needed to import additional trusted certificates into the trust store in order to make the service call over SSL.  At many of our customers this is an internal Root CA they use to sign their own certificates for internal use.

When looking at the default settings of the IntegratedServer in JDeveloper 12c we can now see below that it is configured by default to use the OPSS Keystore Service and not a JKS Trust Store.

You can see above that instead of a filesystem URI to a JKS file you now see a kss:// URI.  This URI shows that we are using the trust store called "trust" in the system strip of the Keystore Service.

The OPSS Keystore Service is meant to provide a single location for Keystores and Trust stores for all applications running within the Weblogic domain.  The only pre-requisite for using the service is that the JRF templates have been applied to your domain, which should be the case for any SOA 12c domain.

Using this service you can now manage all of your certificates through Fusion Middleware Control and WLST.  You can navigate to the Security -> Keystore menu under your domain in FMW Control as shown below.

Once on the Keystore page you can select the keystore called trust under the system stripe and select manage.

On the Manage Certificates page you can now see a list of all certificates in the keystore.  From here you have several operations you can perform such as:

  • Generate a Keypair
  • Generate a CSR for a Keypair
  • Import Certificate
  • Import Trusted Certificate
  • Export Certificates
  • Delete Certificates

In this case we needed to import several Trusted Certificates so we can simply select the Import button.

Now we select Trusted Certificate as the type and provide an alias for the certificate.

We can then either paste in the PEM formatted certificate or select it as a file to upload.


Once imported you should see confirmation that the certificate was imported successfully and you should see the new certificate listed in the table.


Once we imported the required certificates we still needed to restart the integrated server before the service invocation began working.

The OPSS Keystore Service now provides one single point of access for administrators and developers to manage all of the keystores required by each application.  This provides administrators a much more user friendly way to generate, sign, and manage their certificates but still allows these actions to be automated through WLST as well.

About the Author

Adam Desjardin

Adam DesJardin is the Chief Technology Officer for AVIO Consulting.  Adam focuses on technical strategy, standards and delivery both within AVIO and for our customers.  Prior to joining AVIO in 2007, Adam held various consulting and architecture positions at Fuego and BEA Systems where he developed and delivered process and service driven solutions.

Join the Conversation

February 5, 2015


We are using custom trust and custom identity. The steps you have done above of importing trusted certificate, is there a way that we can do it via command line (either WLST or simple use of keytool commands) to import trusted certificate to the 'trust'?

June 10, 2015

Nice article , but can you let me know once we import our certificate , which keystore is updated in the backend and what is the location.

I still see handshake exceptions post importing the certificates.

June 29, 2015

As Raghav asked can you please give the file which is updated after we import root certs.

Adam Desjardin
June 29, 2015

The keystores are stored in the OPSS DB schema when using the keystore service.

You can export a specific keystore to a JKS file using WLST.

See the Oracle documentation below for the available WLST management commands:

David Gaskell
March 8, 2016


If a Cert is added to the system/trust stripe as above. Is there any additional configuration required to utilise this? I seem to be getting SSL cert errors when initiating the HTTPS endpoint when consumed via OSB

Many Thanks

Francisco Lomas
April 14, 2016

There is a missing step here, syncKeyStores, if your OSB instance is not in the same box it will never work

Francisco Lomas
April 14, 2016

for syncKeyStores you can:

- Use the Enterprise Manager MBean Browser, look for the command, use the 2 paramteres command, execute it with the parameters: system, KSS

- Use of the domain, connect to the admin server, execute: syncKeyStores('system', 'KSS') -> Use the in the same box as the admin server

- Restart the instances

Then it will work, syncKeyStores is documented that need to be called if you update the domain trust store, small mising step.

April 15, 2016


Nice article.


Do you have the screenshot for SOA 12.2.1 version?

I am getting below error after importing the certificates.

Message send failed: PKIX path building failed: unable to find valid certification path to requested target.

May 26, 2016

Hi Lalit,

For SOA 12.2.1 , check your setDomainenv.cmd / file and check for the line where DemoTrust.jks is mentioed.

Remove that section and then restart the server.

It should work 

May 27, 2016


I have an owsm stripe + keystore in it configured.  everything works fine;

now I had to change the  current certificate in the keystore with a new one. (delete current , import new)

when testing it, we get this error :WSM-00340 : The key for the alias myoldkey not found in the KSS Keystore

It looks like owsm is still searching for the old alias in the owsm keystore instead of the new one.

in this blog I read to use the syncKeyStores command , which I did now : syncKeyStores('owsm','KSS')

but this gives me this error :

JPS-06633: Cannot synchronize component key store(s) under stripe owsm into corresponding wallets. Reason JPS-06530: Invalid stripe value owsm

        at weblogic.utils.StackTraceDisabled.unknownMethod()

Caused by: JPS-06633: Cannot synchronize component key store(s) under stripe owsm into corresponding wallets. Reason JPS-06530: Invalid stripe value owsm

any ideas what could be the problem on both errors  (wsm-00340, jps-06530)

many thanks

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.