Click OK to submit the changes.

Setting Up Your Environment for Policies 10-15 Obtaining a Trusted Certificate and Importing it into the Keystore You can obtain a certificate from a Certificate Authority CA, such as Verisign or Entrust.net, and include it in the keystore. 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 obtain a trusted certificate and import the certificate into the keystore:

1. Generate the private key and self-signed certificate. The self-signed certificate will

be replaced by the trusted certificate. Use the keytool -genkeypair command to generate the key pair for a specified alias, in this example orakey. It will create the keystore if it did not exist. keytool -genkeypair -keyalg RSA -alias orakey -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600

2. Generate the certificate request.

Use the keytool -certreq command to generate the request. The following command generates a certificate request for the orakey alias and a Certificate Signing Request CSR named certreq_file. keytool -certreq -alias orakey -sigalg SHA1withRSA -file certreq_file -storetype jks -keystore default-keystore.jks

3. Submit the CSR file to a CA such as VeriSign, for example. The CA will

authenticate the request and return a certificate or a certificate chain.

4. Import the CA root certificate which authenticates the CA’s public key.

Use the keytool -importcert command to import the trusted CA root certificate named VerisignCAcert.cer in this example, using the alias verisignca into the default-keystore.jks keystore. The keytool utility prompts for the needed password. keytool -importcert -alias verisignca -trustcacerts -file VerisignCAcert.cer -keystore default-keystore.jks

5. Replace the self-signed certificate with the trusted CA certificate issued by the CA

in response to the certificate request. Use the keytool -importcert command. The following command replaces the self-signed certificate for the alias orakey with the trusted CA certificate named, in this example, MyCertIssuedByVerisign.cer. The keytool utility prompts for the needed password. keytool -importcert -trustcacerts -alias orakey -file MyCertIssuedByVerisign.cer -keystore default-keystore.jks Note: If your keystore already contains a self-signed certificate that you created previously, as described in Generating Private Keys and Creating the Java Keystore on page 10-9, you can ignore this step and proceed to step 2. 10-16 Oracle Fusion Middleware Security and Administrators Guide for Web Services Setting Up the Web Service Client Keystore at Design Time You need to create a Java Key Store JKS keystore to store the signature and encryption keys required by the X.509 token on the client. Keys are used for a variety of purposes, including authentication and data integrity. For example: ■ To sign data, you must have the signers private key. ■ To verify a signature, you must have a trusted CA certificate and the public key that matches the private key. ■ To encrypt data, you must have the recipients public key. The Web services base64-encoded public certificate is published in the WSDL for use by the Web service client, as described in Using Service Identity Certification Extension on page 10-37. ■ To decrypt data, you must have the private key that corresponds to the public key. These trusted certificates and public and private keys are stored in the keystore. The following sections describe the requirements for the different types of message protection policies, how to create and use these keystores, and how to obtain trusted certificates. ■ How Different Security Policies Use Private Keys and Certificates on page 10-3 ■ Generating Private Keys and Creating the Java Keystore on page 10-9 ■ Obtaining a Trusted Certificate and Importing it into the Keystore on page 10-15 Configuring the Credential Store Oracle WSM uses the Credential Store Framework CSF to manage the credentials in a secure form. The CSF provides a way to store, retrieve, and delete credentials for a Web Service and other applications. Oracle WSM uses the credential store to look up the following: ■ Alias names and passwords for keys in the Java keystore For details about how Oracle WSM uses the credential store to look up alias names and passwords from the Java keystore, see How Oracle WSM Locates Keystore And Key Passwords on page 10-21. ■ Usernames and passwords used for authentication Suppose, for example, that you have a Web service that accepts a username token for authentication. If you create a Web service client to talk to this Web service, you need to configure the Web service client with a username and password that can be sent to the Web service. You store this username and password in the credential store using either Fusion Middleware Control or WLST and assign it a csf key. For example, the oraclewss_username_token_client_policy policy includes the csf-key property, with a default value of basic.credentials. To use the wss_username_token_client_policy, you should create a new password credential in the CSF using the credential name basic.credentials, and the username and password with which the client needs to connect . If you have two Web service clients that use this same client policy, these clients can either share the same password credential, which defaults to basic.credentials, or each one can have its own credential. In the latter case, you need to create two password credentials in the CSF, for example App1.credentials and App2.credentials, for Client1 and Client2 respectively. For Client1, you set the csf-key configuration override to App1.credentials, and for Client2, you set Setting Up Your Environment for Policies 10-17 the csf-key property to App2.credentials. For more information, see Attaching Client Policies Permitting Overrides on page 8-21. Note that in both cases, the usernames and passwords must represent valid users in the OPSS identity store. A password credential can store a username and password. A generic credential can store any credential object. The CSF configuration is maintained in the jps-config.xml file in the domain-home configfmwconfig directory. When you configure the Oracle WSM keystore using Fusion Middleware Control, as described in Configuring the Oracle WSM Keystore on page 10-10, the aliases and passwords that you specify are securely stored in the credential store. If, however, you add other aliases to the keystore, or you need to add authentication credentials for a client, you need to ensure that they are configured and stored in the credential store also, as described in the following section. Adding Keys and User Credentials to the Credential Store You can use Fusion Middleware Control or WLST commands to add keys and user credentials to the credential store. Both methods are described in the following procedures. Using Fusion Middleware Control Follow these steps in Fusion Middleware Control to add keys and certificates to the credential store:

1. In the Navigator pane, expand WebLogic Domain to show the domain for which

you need to configure the keystore. Select the domain.

2. From the WebLogic Domain menu, select Security then Credentials.

Note: The example procedures in this section describe how to add user credentials for the basic.credentials key as described above, and the example ServiceA and ServiceB aliases described in Advanced Setup Considerations on page 10-8. In your own environment, you should use aliases and passwords that are appropriate for your configuration. Before adding key credentials to the credential store, ensure that the private keys and aliases exist in the keystore. You can create them using commands such as the following: keytool -genkeypair -keyalg RSA -alias ServiceA -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600 keytool -genkeypair -keyalg RSA -alias ServiceB -keypass welcome3 -keystore default-keystore.jks -storepass welcome1 -validity 3600 For more information about the keystore, see Generating Private Keys and Creating the Java Keystore on page 10-9.