1. Using Oracle WebLogic Server on Microsoft Azure IaaS (Oracle Linux x86-64)
  2. Common Administration Tasks
  3. Configure Keystores

Configure Keystores

TLS/SSL provides secure connections by allowing two applications connected over a network to authenticate each other's identity, and by encrypting the data exchanged between the applications.

Authentication allows a server and optionally a client to verify the identity of an application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.

TLS/SSL in Oracle WebLogic Server

TLS/SSL in WebLogic Server is an implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) specifications. WebLogic Server supports TLS/SSL on a dedicated listen port which defaults to 7002. For more information about configuring SSL in an Oracle WebLogic Server environment, see Configuring SSL.

By default, WebLogic Server provides demo certificates or keystores for working in a development or a test environment. Ensure that these certificates are not used in a production environment.

Self-signed certificates are created and configured in WebLogic Server in development or test environments. For a production environment, you must procure CA-signed TLS/SSL certificate from a valid Certificate Authority (CA), such as Verisign, Let’s Encrypt, GoDaddy and so on, to create keystores from it.

To configure SSL in WebLogic Server, you need the following security files:

  • Trust store: This file contains the certificates from the intermediate or root CA, or from any trusted third parties that are used in the TLS/SSL communication.
  • Identity store: The identity store (or keystore) file contains the private key and the server TLS/SSL certificates. This file is stored in either JKS or PKCS12 format.

Keystore Formats

Keystore is a storage facility to store cryptographic keys and certificates. The supported keystore formats are:

  • JKS - Java Key Store
  • PKCS12 - Public Key Cryptography Standards

Keypass and Storepass

Keypass is a password used to protect the private key of a generated key pair. Storepass is a password used to protect the integrity of a keystore. If you don't provide a keypass, then the keypass is set to the same value as the storepass.

Identity and Trust Keystores

WebLogic Server uses private keys, digital certificates, and trusted certificates issued by certification authorities to establish and verify server identity and trust. See Identity and Trust in Understanding Security for Oracle WebLogic Server.

To create identity and trust keystores, you must use the keytool utility. Keytool is a key and certificate management utility that is included in the JDK. For more information, refer to the following topics:

Parent topic: Common Administration Tasks

Create Identity and Trust Keystores for Self-Signed Certificates

Use the keytool utility to create identity and trust keystores for self-signed certificates.

To do this:
  1. Create an identity keystore:
    keytool -genkey -alias <private_key_alias> -keyalg <key_algorithm> -keysize <key_size> -sigalg <signature_algorithm> -validity <validity_period_in_days> -keystore <keystore_fileName> -keypass <key_passphrase> -storepass <identity_keystore_passphrase>

    For example:

    keytool -genkey -alias servercert -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 365 -keystore identity.jks -keypass identityKeyPassword -storepass identityStorePassword
  2. (Optional) To use the identity keystore in PKCS12 format, convert the keystore from JKS type to PKCS12 type:
    keytool -importkeystore -srckeystore <keystore_file_in_JKS_Format> -destkeystore <keystore_file_in_PKCS12_format> -deststoretype pkcs12

    For example:

    keytool -importkeystore -srckeystore identity.jks -destkeystore identity.p12 -deststoretype pkcs12
  3. Export the identity keystore to create a certificate:
    keytool -export -alias <private_key_alias> -noprompt -file <certificate_name> -keystore <identity_keystore_filename> -storepass <identity_keystore_passphrase>

    For example:

    keytool -export -alias servercert -noprompt -file server.cert -keystore identity.jks -storepass identityStorePassword
  4. Import the certificate into the trust keystore:
    keytool -import -alias <trust_store_alias> -noprompt -file <certificate_name> -keystore <trust_keystore_filename> -storepass <trust_keystore_passphrase>

    For example:

    keytool -import -alias trustcert -noprompt -file root.cert -keystore trust.jks -storepass trustKeyStorePassword
  5. (Optional) To use the trust keystore in PKCS12 format, convert the keystore from JKS type to PKCS12 type:
    keytool -importkeystore -srckeystore <keystore_file_in_JKS_Format> -destkeystore <keystore_file_in_PKCS12_format> -deststoretype pkcs12

    For example:

    keytool -importkeystore -srckeystore identity.jks -destkeystore identity.p12 -deststoretype pkcs12
  6. Validate the identity and trust keystores:
    keytool  -list -v -keystore <keystore_file>

    For example:

    keytool -list -v -keystore identity.jks -storepass identityStorePassword
keytool -list -v -keystore trust.jks -storepass trustKeyStorePassword

Parent topic: Configure Keystores

Create Identity and Trust Keystores for CA-Signed Certificate

Use the keytool utility to create identity and trust keystores for self-signed certificates.

To do this:
  1. Create a keystore:
    keytool -keystore <keystore_file_in_JKS_Format> -genkey -alias <private_key_alias>

    For example:

    keytool -keystore clientkeystore -genkey -alias client

    Enter the required details when prompted. For example:

    Enter keystore password: javacaps
What is your first and last name?
[User]:  example.org.com
What is the name of your organizational unit?
[User]:  Development
What is the name of your organization?
[User]:  example org
What is the name of your City or Locality?
[User]:  San Francisco
What is the name of your State or Province?
[User]:  California
What is the two-letter country code for this unit?
[User]:  US
Is <CN=example.org.com, OU=Development, O=example org, L=San Francisco, ST=California, 
C=US> correct?
[no]:  yes

Enter key password for <client>
(RETURN if same as keystore password):
  2. Generate a Certificate Signing Request (CSR):
    keytool -keystore <keystore_file> -certreq -alias <private_key_alias> -keyalg <key_algorithm> -file
      <certificate_signing_request_file>

    For example:

    keytool -keystore clientkeystore -certreq -alias client -keyalg rsa -file client.csr

    Enter the required details when prompted. For example:

    Enter keystore password:
Re-enter new password:
What is your first and last name?
  [User]: example.org.com
What is the name of your organizational unit?
  [User]: Development
What is the name of your organization?
  [User]: example org
What is the name of your City or Locality?
  [User]: San Francisco
What is the name of your State or Province?
  [User]: California
What is the two-letter country code for this unit?
  [User]: US
Is CN=example.org.com, OU=Development, O=example org, L=San Francisco, ST=California, C=US correct?
  [no]: yes

Enter key password for <client>
        (RETURN if same as keystore password):
Re-enter new password:
  3. Submit the Certificate Signing Request to Certification Authority (CA):

    Submission of CSR to CA can be done online or through Email. After the CSR is received by the CA, the request will be verified and a TLS/SSL certificate will be issued. After the verification process is complete, the CA either sends the TLS/SSL certificate over an Email or provides access to the client to download the certificate using an online account.

    The Certification Authority provides a ZIP file that contains:

    • Server SSL Certificate
    • Root and Intermediate Certificates
    • Private Key

    Note:

    The CA can provide a combined or a separate root and intermediate certificates. Also, there can be multiple intermediate certificates. The root and intermediate certificates need to be combined to form a single certificate, which can be used to configure TLS/SSL in WebLogic Server.
  4. Create a combined certificate by doing the following:
    1. Open a text editor.
    2. Copy the contents of the root certificates including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, and paste them one below the other in the text editor.
    3. Save the file as combined.crt.
  5. Validate the combined certificate:
    bash>openssl verify -CAfile combined.crt certificate.crt
certificate.crt: OK
  6. Create a trust store file:
    keytool -noprompt -import -alias <server_alias> -file <CA_certificate> -keystore <trust_store_file> -storepass <trust_store_password>

    For example:

    keytool -noprompt -import -alias trustcert -file ca_bundle.crt -keystore trust.jks -storepass mypassword
    If there are multiple root or CA certificates, import them individually into the same keystore file. For example:
    keytool -import -file /u01/app/cascerts/rootCA.cert -alias rootCA -keystore trust.jks
keytool -import -file /u01/app/cascerts/firstCA.cert -alias firstCA -keystore trust.jks
keytool -import -file /u01/app/cascerts/secondCA.cert -alias secondCA -keystore trust.jks
keytool -import -file /u01/app/cascerts/thirdCA.cert -alias thirdCA -keystore trust.jks
  7. Merge all intermediate certificates into one file (for example, combined.crt):
    cat ca_1.crt ca_2.crt > combined.crt
  8. Create an identity store file:
    openssl pkcs12 -export -in <server_certificate> -inkey <private_key> -chain -CAfile <combined_certificate_file> -name <private_key_alias> -out <identity_keystore_in_PKCS12_format>

keytool -noprompt -importkeystore -destorepass <destination_store_password> -destkeystore <destination_keystore_file> -srckeystore <source_keystore_file> -srcstoretype <source_keystore_type> -srcalias <source_alias> -destalias <destination_alias> -srckeypass <source_key_password>

    For example:

    openssl pkcs12 -export -in certificate.crt -inkey private.key -chain -CAfile combined.crt -name servercert -out mycert.p12

keytool -noprompt -importkeystore -deststorepass mypassword -destkeystore identity.jks -srckeystore mycert.p12 -srcstoretype PKCS12 -srcalias servercert -destalias servercert -srckeypass mypassword

Parent topic: Configure Keystores

Store Keystores and Passphrases in Azure Key Vault

Secure key management is essential to protect data in the cloud.

An Azure Key Vault lets you to store the TLS/SSL certificates, confidential keys, and other secrets, such as passwords. The following example shows how to store TLS/SSL certificates and keystores in Azure KeyVault:

az keyvault secret set --vault-name mySecureKeyVault  --encoding base64 --description text/plain --name identityKeyStoreData --file identity.jks
az keyvault secret set --vault-name mySecureKeyVault  --name "identityKeyPassPhrase" --value "identityKeyPassword"
az keyvault secret set --vault-name mySecureKeyVault  --encoding base64 --description text/plain --name trustKeyStoreData --file trust.jks
az keyvault secret set --vault-name mySecureKeyVault  --name "trustKeyPassPhrase" --value "trustKeyPassword"
az keyvault secret set --vault-name mySecureKeyVault  --name "privateKeyAlias" --value "servercert"
az keyvault secret set --vault-name mySecureKeyVault  --name "privateKeyPassPhrase" --value "myPrivateKey"

For more information about managing the Azure Key Vault secrets, see Microsoft documentation on Azure Key Vault Secrets.

Parent topic: Configure Keystores