Managing Keys and Certificates

12 Managing Keys and Certificates

The keystore service allows you to manage and administer keys and certificates for Secure Sockets Layer (SSL), message security, encryption, and other tasks that require special certificates.

This chapter includes the following topics:

Parent topic: OPSS Services

About the Keystore Service

The Keystore Service allows you to manage keys and certificates for SSL, message security, encryption, and other tasks that require a key or a certificate. Typical keystore management tasks include the following:

Creating a keystore in the context of an application stripe, directly or by importing a keystore file from the file system.
Viewing the list of keystores and choosing some for updating.
Updating and deleting keystores.
Changing the keystore password.
Exporting and importing keystores.

The following topics introduce Keystore Service concepts:

Parent topic: Managing Keys and Certificates

Structure of the Keystore Service

A keystore is uniquely identified by an application stripe and a keystore within that stripe. Keys and certificates are created in keystores within stripes. Stripe names must be unique in the security store, and keystore names within a stripe must be unique in the stripe. For example,(stripe1,keystoreA), (stripe1,keystoreB), and(stripe2,keystoreA)refer to three distinct keystores.

Applications can create more than one keystore within the application stripe.

A keystore can contain the following entries, referenced by a unique alias within the keystore:

Asymmetric Keys, including public keys and private keys that are used with SSL. Public keys are wrapped within a certificate.
Symmetric Keys, generally used for encryption.
Trusted Certificates, used to establish trust with an SSL peer.

Parent topic: About the Keystore Service

Types of Keystores

The Keystore Service allows you to create two types of keystores:

Keystores protected by a policy

These keystores are protected by policies and any access to them by runtime code is protected by codesource policies. The key data is encrypted with the domain encryption key.
Keystores protected by password

These keystores are protected by keystore and/or key passwords. Any access to them by runtime code requires access to the keystore and key password (if different from the keystore password). The key data is encrypted with the keystore/key password with password-based encryption.

Oracle recommends that you use password-protected keystores. However, if your application requires a high security level, then consider using a keystore protected by a codesource policy. You can export, import, and restore keys to a wallet.

In domains with multiple servers, the only supported store types are LDAP or DB. Do not use the keystore service to manage passwords or keys. Instead, use the credential store for your application.

Parent topic: About the Keystore Service

The Truststore

The truststore is a keystore that contains trusted certificates of most well-known third-party certificate authorities and a trusted certificate from the demonstration certification authority (CA), which is configured with the Keystore Service. If your application uses SSL, for example, it can point to the truststore for certificates, and you do not need a dedicated keystore to store them.

Caution:

The demonstration CA includes a hard-coded private key. Oracle recommends that you neither use nor trust the demonstration CA certificates in production environments. For more information about replacing the demo CA certificates, see the following topics:

The truststore is shared by all products and applications in a domain. The decision to add or remove trust for a product may affect other products in the domain. Consider creating a custom truststore only if your product's trust management requirements are not met by the truststore.

A truststore is preconfigured for all products and applications to use, and applications can configure multiple keystores, according to their needs.

One-Way SSL,

For one-way SSL, applications can use the truststore and you do not need to create a specific keystore.

Two-Way SSL

For two-way SSL, applications create a keystore to keep just their identity certificate and use the truststore for other certificates.

Parent topic: About the Keystore Service

About Keystore Service Commands

The Keystore Service uses a dedicated set of commands for keystore operations such as creating and managing keystores, exporting certificates, and generating key pairs. While their usage is similar, these commands are distinct from other OPSS commands.

The starting point to all these commands is the getOpssService command, which gets an OPSS service command object that lets you:

Execute commands for the service
Obtain command help

The command syntax is:

variable = getOpssService(name='service_name')

In this command:

variable stores the command object.
service_name refers to the service whose command object is to be obtained. The only valid value is 'KeyStoreService'.

For example:

svc = getOpssService(name='KeyStoreService')

Parent topic: Managing Keys and Certificates

Getting Help for Keystore Service Commands

To obtain help for any Keystore Service command, start by obtaining a service command object. Then use this object in conjunction with the help command and the command in question.

To obtain the service command object and the list of all Keystore Service commands, enter:

svc = getOpssService(name='KeyStoreService')
svc.help()

To obtain help for a specific command, enter:

svc.help('command-name')

For example, the following returns help for the exportKeyStore command:

svc.help('exportKeyStore')

Parent topic: About Keystore Service Commands

Keystore Service Command Reference

For syntax and reference information about the Keystore Service commands, see OPSS Keystore Service Commands in the WLST Command Reference for Infrastructure Security.

Parent topic: About Keystore Service Commands

Managing Keystores with Fusion Middleware Control

You must perform the following tasks to manage keystores with Oracle Enterprise Manager Fusion Middleware Control.

Task 1, Opening the Keystore Page

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.

Task 2, Creating a Keystore

Choose the stripe in which to create the keystore. If necessary, then create a stripe.
Click Create Keystore. The Create Keystore dialog is displayed.
In this dialog, enter the following data:
- Keystore Name: a unique name.
- Protection Type: the protection mechanism for the keystore. Choose Policy or Password. For a password-protected keystore, provide a valid password.
- Grant Permission: check this box to grant permissions to code URL.
Click OK. The new keystore is displayed under the stripe you chose.

Task 3, Deleting a Keystore

When you delete a keystore, note that all certificates in it are also deleted.

Expand the stripe in which the keystore resides, and choose a row.
Click Delete. The Delete Keystore dialog is displayed.
If this is a password-protected keystore, then enter the password.
Click OK.

Task 4, Changing a Keystore Password

This task applies to password-protected keystores only.

Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore.
Click Change Password. The Change Keystore Password dialog is displayed.
Enter the old and new passwords.
Click OK.

Parent topic: Managing Keys and Certificates

Managing Keystores with WLST

You must perform the following tasks to manage keystores with WebLogic Scripting Tool (WLST).

Task 1, Creating a Keystore

Use the createKeyStore WLST command. For example, assuming the stripe name is teststripe1, create a permission-based keystore:

svc.createKeyStore(appStripe='teststripe1', name='keystore1', password='password',permission=true)

where password is the password for keystore1. Any combination of characters is allowed for a new stripe name, but it is recommended that you do not use the forward slash (/) in it. The keystore name must unique.

Task 2, Deleting a Keystore

Use the deleteKeyStore WLST command. For example, assuming the stripe is appstripe1, delete keystore1:

svc.deleteKeyStore(appStripe='appstripe1', name='keystore1', password='password')

where password is the password for keystore1.

Task 3, Changing a Keystore Password

Use the changeKeyStorePassword WLST command. For example, assuming the stripe name is system, change the password of keystore2:

svc.changeKeyStorePassword(appStripe='system', name='keystore2', currentpassword='currentpassword', newpassword='newpassword')

where currentpassword and newpassword are the old and new passwords.

Task 4, Exporting a Keystore

Use the exportKeyStore WLST command.

To export a singe key to a file:

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JKS',filepath='/tmp/file.jks')

To export multiple keys to a file, specify a comma-separated list of aliases and key passwords.

To export a symmetric key:

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JCEKS',filepath='/tmp/file.jks')

To export to a wallet, use the OracleWallet type:

svc.exportKeyStore(appStripe='mystripe', name='keystore3', password='password',aliases='myorakey1,myorakey2', keypasswords='', type='OracleWallet',filepath='/tmp')

Task 5, Importing a Keystore

Use the importKeyStore WLST command.

To import a single key, such as myOrakey:

svc.importKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myOrakey', keypasswords='keypassword1', type='JKS', permission=true, filepath='/tmp/file.jks')

To import multiple keys, specify a comma-separated list of aliases and key passwords.

To import keys from a wallet, use the OracleWallet type:

svc.importKeyStore(appStripe='mystripe', name='keystore4', password='password',aliases='myorakey1,myorakey2', keypasswords='', type='OracleWallet', permission=true, filepath='/tmp')

Parent topic: Managing Keys and Certificates

About Certificates

The Keystore Service (KSS) keystore supports the Java Keystore (JKS), Java Cryptography Extension Keystore (JCEKS), and Oracle wallet certificate formats. Typical certificate management tasks include the following:

Creating a certificate for a key pair.
Generating a Certificate Signing Request (CSR) for the certificate and saving it to a file.
Sending the CSR to a certificate authority who verifies the sender, and signs and returns the certificate.
Importing user and trusted certificates into the keystore, by either pasting it into a text field or importing it from the file system.

Note:

Keystore Service supports importing PEM/BASE64-encoded certificates only. You cannot import DER-encoded certificates or trusted certificates into a keystore.
Exporting certificates or trusted certificates from the keystore to a file.
Deleting certificates or trusted certificates from the keystore.

The following points regarding public CA certificates apply to domains upgraded to 12.2.1 and to new 12.2.1 Java Required Files (JRF) domains:

Well-known public CA certificates are no longer available in the trust keystore in the system stripe.
Use instead the publiccacerts keystore in the system stripe, which has been previously seeded with well-known public CA certificates from the Java SE Development Kit (JDK) cacerts file. Alternatively, import your own certificates as needed.
The merge.jdkcacerts.with.trust property specifies whether to return public CA certificates in the kss://system/ubliccacerts keystore when you query the kss://system/trust keystore. Set to true, to have all publicacerts certificates returned with the query. Do not set or set to false, to have no publicacerts certificates returned with the query.

Managing Certificates with Fusion Middleware Control

You must perform the following tasks to manage keystores with Fusion Middleware Control.

Task 1, Generating a Key Pair

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the keystore password and click OK. The Manage Certificates page is displayed.
Click Generate Keypair. The Generate Keypair dialog is displayed.
In this dialog, enter the following data:
- Alias (required)
- Common Name (required)
- Subject Alternative Name
- Organizational Unit
- Organization
- City
- State
- Country: Choose one from the drop-down list.
- Key Type: Choose an algorithm from the drop-down list. The choices are Elliptic Curve Cryptography (ECC) or RSA.
- Key Size: Choose a key size.
Click OK. The new certificate is displayed in the certificate list.
View the certificate details by clicking on the certificate alias.

The key pair is wrapped in a demonstration CA signed certificate and stored in the truststore. To use this certificate for SSL, applications must either use the truststore or import the demonstration CA certificate to a custom keystore.

Task 2, Generating a CSR for a Certificate

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the keystore password and click OK. The Manage Certificates page is displayed.
Choose the row corresponding to the certificate and click Generate CSR. The Generate CSR dialog appears
Do one of the following:
- Copy and paste the entire CSR into a text file, and click Close.
- Click Export CSR to save the CSR to a file.

Send the generated certificate to a certificate authority which will return a signed certificate.

Task 3, Importing a Certificate

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the password and click OK. The Manage Certificates page is displayed.
Click Import. The Import Certificate dialog is displayed.
Choose Certificate or Trusted Certificate from the drop-down.
Choose the alias from the drop-down.
Specify the certificate source. If using the Paste option, then copy and paste the certificate directly into the text field. If using the Select a file option, then click Browse to choose the file from the operating system.
Click OK. The imported certificate or trusted certificate is displayed in the list of certificates.

Task 4, Exporting a Certificate

Log in to Fusion Middleware Control and go to Domain, then to Security, that then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the password and click OK. The Manage Certificates page is displayed.
Choose the row corresponding to the certificate and click Export. The certificate export dialog is displayed.
Do one of the following:
- Copy and paste the entire certificate into a text file, and click Close.
- Click Export Certificate to save the certificate to a file.

Task 5, Changing a Certificate Password

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the password and click OK. The Manage Certificates page is displayed.
Choose the row corresponding to the certificate and click Change Password. The Change Key Password dialog appears
Enter the old and new passwords and click OK.

Task 6, Deleting a Certificate

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Keystore. The Keystore page is displayed.
Expand the stripe in which the keystore resides. Choose the row corresponding to the keystore, and click Manage.
If the keystore is password-protected, then enter the password and click OK. The Manage Certificates page is displayed.
Choose the row corresponding to the certificate and click Delete. The Delete Certificate dialog is displayed. Click OK.

Parent topic: Managing Keys and Certificates

Managing Certificates with WLST

You must perform the following tasks to manage certificates with WLST.

Task 1, Generating a Key Pair

Use the generateKeyPair WLST command. For example, assuming an application stripe named appstripe2, the following command creates a key pair with the myalias alias using the ECC algorithm:

svc.generateKeyPair(appStripe='appstripe2', name='keystore2', password='password', dn='cn=www.example.com', keysize='1024', alias='myalias', keypassword='keypassword', algorithm='EC')

where password is the keystore password and keypassword is the password of the alias.

The key pair is wrapped in a demonstration CA certificate and stored in the truststore. If your application is not using the truststore, then you must import the demonstration CA certificate to a custom keystore.

The following example generates a keypair in keystore2 using the default RSA algorithm:

svc.generateKeyPair(appStripe='system', name='keystore2', password='password', dn='cn=www.oracle.com', keysize='2048', alias='orakey', keypassword='keypassword')

You can pass a Subject Alternative Name (SAN) extension using the optional ext_san argument. The format for the argument is "type:value,...,type:value". Only the DNS type is supported.

The following example generates a keypair with a SAN extension in keystore2 using the default RSA algorithm:

svc.generateKeyPair(appStripe='system', name='keystore2', password='password', dn='cn=www.oracle.com', keysize='2048', alias='orakey', keypassword='keypassword', 
ext_san='DNS:server1.oracle.com,DNS:www.oracle.com')

Task 2, Generating a CSR for a Key Pair

Use the exportKeyStoreCertificateRequest WLST command. For example, assuming an application stripe is stripe1, the following command generates a CSR from the testalias key pair:

svc.exportKeyStoreCertificateRequest(appStripe='stripe1', name='keystore1', password='password', alias='testalias', keypassword='keypassword', filepath='/tmp/csr-file')

where password is the keystore password and keypassword is the password of the alias. The CSR is exported to an operating system file.

Task 3, Importing a Certificate

Use the importKeyStoreCertificate WLST command. For example, assuming the appstripe1 application stripe, the following command imports a certificate with mykey alias from an operating system file:

svc.importKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='password', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

where password is the keystore password and keypassword is the password of the alias.

Task 4, Exporting a Certificate

Use the exportKeyStoreCertificate WLST command. For example, assuming the appstripe1 application stripe, the following command exports a certificate with mykey alias to an operating system file:

svc.exportKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='password', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt/')

where password is the keystore password and keypassword is the password of the alias.

Note:

The directory specified using the filepath parameter must exist before exporting the keystore.

Task 5, Changing a Certificate Password

Use the changeKeyPassword WLST command. For example, assuming the system1 system stripe, the following command deletes a certificate with testkey alias:

svc.changeKeyPassword(appStripe='system1', name='keystore', password='password', alias='testkey', currentkeypassword='currentkeypassword', newkeypassword='newkeypassword')

where password is the keystore password and keypassword is the password of the certificate alias.

Task 6, Deleting a Certificate

Use the deleteKeyStoreEntry WLST command. For example, assuming the appstripe application stripe, the following command deletes a certificate with orakey alias:

svc.deleteKeyStoreEntry(appStripe='appstripe', name='keystore2', password='password', alias='orakey', keypassword='keypassword')

where password is the keystore password and keypassword is the password of the alias.

Parent topic: Managing Keys and Certificates

Replacing Demonstration CA Signed Certificates

Oracle highly recommends that you use third-party Certificate Authority (CA) signed certificates or domain CA signed certificates when you deploy applications to a production environment. By default, any certificates created using the OPSS keystore service in the domain are signed using the demonstration CA. These demonstrations certificates should never be used in a production environment. The private key of the demonstration certificate is available to all installations of WebLogic Server, therefore each installation can generate a demo signed CA certificate using the same key. As a result, you cannot trust these certificates.

A domain CA is a self-signed certificate that acts like a CA for a domain. Unlike a demonstration CA, the private key used in a domain CA certificate is unique to each domain, and provides more security. You can create a domain CA certificate and replace all the demonstration CA certificates in a domain as described in Replacing Demo CA Certificates With Domain CA Signed Certificates.

A third-party CA validates identities and issues certificates. To get the certificate, you must create a Certificate Request and submit it to the CA. The CA will authenticate the certificate requestor and create a digital certificate based on the request. To replace demonstration certificates with third-party CA signed certificates, see Replacing Demo CA Certificates With Third-Party CA Signed Certificates.

Replacing Demo CA Certificates With Domain CA Signed Certificates
Replacing Demo CA Certificates With Third-Party CA Signed Certificates
Replacing the Demo CA Trust Service Certificate
Setting Up a Security Hardened Domain: An Example
The following example procedure applies the steps provided in the previous sections to illustrate how you can set up a domain that uses either third-party CA signed or internal CA signed certificates throughout the domain in place of the demonstration CA certificates.

Parent topic: Managing Keys and Certificates

Replacing Demo CA Certificates With Domain CA Signed Certificates

To replace all the demonstration CA signed certificates in the domain with domain CA signed certificates, use the following procedure:

Use the keytool command to create a .p12 file for PKCS12 keystore as shown below:

Linux:

keytool -genkeypair -alias customca -keyalg RSA -keysize 2048 -dname "cn=customca, o=oracle" -validity 3650 -keystore /tmp/file.p12 -storepass password1 -keypass password1

Windows:

keytool -genkeypair -alias customca -keyalg RSA -keysize 2048 -dname "cn=customca, o=oracle" -validity 3650 -keystore 'c:\temp\file.p12' -storepass password1 -keypass password1

Note:

For the PKCS12 keystore, both the storepass and keypass must have the same value.

Import the keystore file into the KSS keystore kss://system/castore using the svc.importKeyStore keystore service online WLST command. Before using this command, you must start WLST and connect to the server. For PKCS12 keystore use type='PKCS12' in the wlst command.

Note:

Before running WLST, if you have configured a secure mode domain only then set these environment variables as described in Connecting to the Administration Server using WLST.

connect("<wls adminuser>","<wls admin password>","t3://<host>:<port>")
svc = getOpssService(name='KeyStoreService')
:
: 

wls:/base_domain/domainRuntime/> svc.importKeyStore(appStripe='system', name='castore', password='password1', aliases='customca',keypasswords='password1', type='PKCS12', permission=true, filepath='/tmp/file.p12')

Windows:


connect("<wls adminuser>","<wls admin password>","t3://<host>:<port>")
svc = getOpssService(name='KeyStoreService')
:
: 

wls:/base_domain/domainRuntime/> svc.importKeyStore(appStripe='system', name='castore', password='password1', aliases='customca',keypasswords='password1', type='PKCS12', permission=true, filepath='c:\\temp\\file.p12')

Note that the values of some parameters used in svc.ImportKeyStore WLST command are derived from the values specified in the keytool command in the previous step. The corresponding parameters, with the sample values used in these commands, are shown in the following table.

Keytool Parameter	svc.importKeyStore Parameter	Sample Value
`-alias`	`aliases=`	customca
`-keystore`	`filepath=`	Linux /tmp/file.p12 Windows c:\\temp\\file.p12
`-storepass`	`password=`	password1
`-keypass`	`keypasswords=`	password1

Verify that the key pair and certificate have been imported correctly into the KSS store. The output of the command should contain an entry with the alias customca, as shown.

wls:/base_domain/domainRuntime/> svc.listKeyStoreAliases(appStripe='system', name='castore', password='', type='Certificate')

Already in Domain Runtime Tree
 
democa
customca

Export the certificate from kss://system/castore, and import it into kss://system/trust. The value of the filepath parameter must be the same in the export and import commands.

wls:/base_domain/domainRuntime/> svc.exportKeyStoreCertificate(appStripe='system', name='castore', password='password1', alias='customca', type='Certificate', filepath='/tmp/cert.txt')

Already in Domain Runtime Tree
 
Certificate exported.

wls:/base_domain/domainRuntime/> svc.importKeyStoreCertificate(appStripe='system', name='trust', password='password1', alias='customca', keypassword='password1', type='TrustedCertificate', filepath='/tmp/cert.txt')

Already in Domain Runtime Tree
 
Certificate imported.

Windows:

wls:/base_domain/domainRuntime/> svc.exportKeyStoreCertificate(appStripe='system', name='castore', password='password1', alias='customca', type='Certificate', filepath='c:\\temp\\cert.txt')

Already in Domain Runtime Tree
 
Certificate exported.

wls:/base_domain/domainRuntime/> svc.importKeyStoreCertificate(appStripe='system', name='trust', password='password1', alias='customca', keypassword='password1', type='TrustedCertificate', filepath='c:\\temp\\cert.txt')

Already in Domain Runtime Tree
 
Certificate imported.

Verify that the certificate has been imported into the kss://system/trust store. The output of the command should include an alias by the name of customca, as shown.

wls:/base_domain/domainRuntime/> svc.listKeyStoreAliases(appStripe='system', name='trust', password='password1', type='TrustedCertificate')

Already in Domain Runtime Tree
 
democa
olddemoca
customca

Add the following property to the jps-config.xml and jps-config-jse.xml files in DOMAIN_HOME/config/fmwconfig in the keystore service instance configured in the default context:
```
<property name="ca.key.alias" value="customca"/>
```
To do so, follow the procedure in Configuring Services with Scripts to create the updateServiceInstanceProperty.py script.

Execute the script as follows:
```
>cd $ORACLE_COMMON/common/bin
>wlst.sh /tmp/updateServiceInstanceProperty.py -si keystore.db -key ca.key.alias -value customca
```
Restart all the servers in the domain. The domain is now ready to function with the new custom CA certificate. The older demoCA certificate and key still exist in the domain, but are not used.
If you wish to use domain CA signed certificates in production, renew the certificates by executing the following online WLST command:
```
svc.listExpiringCertificates(days='9999', autorenew=true)
```

Parent topic: Replacing Demonstration CA Signed Certificates

Replacing Demo CA Certificates With Third-Party CA Signed Certificates

For each demo certificate in the domain that needs to be replaced with a third-party CA signed certificate, do the following:

Generate a CSR using the alias of the certificate that needs to be replaced. Note that the alias must be of type "Certificate", and not "TrustedCertificate".
Submit the new CSR to a third-party Certificate Authority (CA). The CA will sign the public key in the CSR and return a CA signed certificate and its own certificate.

Some CAs return a certificate chain containing both the CA signed certificate and its own certificate, instead of two separate certificates.
Import the CA signed certificate (or the certificate chain) using the alias of the certificate that is being replaced.
If the CA has provided its own certificate separately, import that CA certificate as a trusted certificate in the trust store used by the product or application. By default, most applications use the domain trust store kss://system/trust for trust.

Replacing the Demo CA Trust Service Certificate

The OPSS trust service certificate is stored in the following keystores in the opss stripe:

trustservice_ks which is a keystore that contains the private key
trustservice_ts which is a trust store that contains the certificate

By default, the trusted certificate is signed using the demonstration CA and has identical copies in both the keystores listed above. To replace it with domain CA or third party CA signed certificate, do the following:

Replace the certificate in stripe opss and keystore trustservice_ks as described in either (but not both) of the following sections:
- Replacing Demo CA Certificates With Domain CA Signed Certificates
- Replacing Demo CA Certificates With Third-Party CA Signed Certificates

Export the certificate from the keystore and import it into the trust store with the stripe opss and keystore trustservice_ts using the following WLST commands:

svc.exportKeyStoreCertificate(appStripe='opss', name='trustservice_ks', password='', alias='trustservice', keypassword='', type='Certificate', filepath='/tmp/cert.txt')

svc.deleteKeyStoreEntry(appStripe='opss', name='trustservice_ts', password='', alias='trustservice', keypassword='')

svc.importKeyStoreCertificate(appStripe='opss', name='trustservice_ts', password='', alias='trustservice', keypassword='', type='TrustedCertificate', filepath='/tmp/cert.txt')

Parent topic: Replacing Demonstration CA Signed Certificates

Setting Up a Security Hardened Domain: An Example

The following example procedure applies the steps provided in the previous sections to illustrate how you can set up a domain that uses either third-party CA signed or internal CA signed certificates throughout the domain in place of the demonstration CA certificates.

Replace the demo CA with the custom CA as described in Replacing Demo CA Certificates With Domain CA Signed Certificates.
Remove the democa trusted certificate from kss://system/trust and add the certificate from the third-party or internal CA. You can do so using the deleteKeyStoreEntry and importKeyStoreCertificate commands, respectively.
In the system/demoidentity and opss/trustservice_ks keystores, replace all demoCA certificates in the deployment with certificates signed by the third-party or internal CA. To do so, follow these steps for each certificate
1. Generate a CSR using the alias of the certificate that needs to be replaced. To do so use the exportKeyStoreCertificateRequest command. For sample usage, see Task 2, Generating a CSR for a Key Pair.
2. Submit the CSR to the third-party or internal CA and obtain a certificate.
3. Import the third-party or internal CA signed certificate into the keystore using the same alias as the certificate it is replacing (it will replace the demo CA signed certificate).
Replace the certificate in opss/trustservice_ts as follows:
1. Export the certificate with alias trustservice from opss/trustservice_ks to a file.
2. Delete the trusted certificate with alias trustservice from opss/trustservice_ts.
3. Import the certificate from the file into the keystore opss/trustservice_ts using the alias trustservice.
For sample usage of these steps and the commands required, see step 2 in Replacing the Demo CA Trust Service Certificate.

Parent topic: Replacing Demonstration CA Signed Certificates

How Fusion Middleware Components Use the Keystore Service

After configuring keystores in Oracle WebLogic Server, use them to generate keys and certificates. You can also configure Node Manager to use the Keystore Service.

Synchronizing the Local Keystore with the Security Store

All Oracle Fusion Middleware components keep keys and certificates in a central security store. However, because certain infrastructure components must be started before the security store is available, some components use a local file keystore instance instead.

To synchronize the local file keystore with the central security store, use the syncKeyStores command. Synchronization is a one-way procedure in which key data is read from the central security store and synchronized in the local file keystore.

Parent topic: How Fusion Middleware Components Use the Keystore Service

syncKeyStores Usage

The usage of the syncKeyStores command is:

syncKeyStores(appStripe='system', keystoreFormat='KSS')

This command accesses the system stripe in the central security store and downloads its contents into a file named keystores.xml in DOMAIN_HOME/config/fmwconfig on the local system.

For more information, see syncKeyStores in WLST Command Reference for Infrastructure Security.

Parent topic: Synchronizing the Local Keystore with the Security Store

When to Synchronize the Keystores

To determine when to use the syncKeyStores command to synchronize the keystores, consider the following:

If the keystore being updated belongs to WebLogic Server, then the keystore should be located under the system stripe.
If you change the domain truststore, such as adding or removing a trusted certificate, you need to execute syncKeyStores to synchronize the local copy used by WebLogic Server with the central security store.
You do not need to execute the syncKeyStores command if a layered component such as Oracle Web Services Manager, or a Jakarta EE application, update the keystore. These components/applications access their keys and certificates from the central security store directly.

Parent topic: Synchronizing the Local Keystore with the Security Store