IBM Support

WebSphere Application Server WS-Security Sample Keys and Certificates are Expired

Troubleshooting


Problem

The WS-Security sample keys and certificates that are shipped with WebSphere Application Server v855 and v9 expired on 8/7/2023 and 8/8/2023.  These sample keys and certificates might be in use by production applications and need to be replaced.
image-20230811021406-1 The WS-Security sample keystores are not intended for use in production environments.  They are intended only for use in example tasks that are published in IBM Docs. 
image-20231208154045-1 If you use the keys and certificates in the WS-Security sample keystores in production, your applications are at risk:
  • Anyone can get these keys and certificates. 
  • Using one of the private decryption keys, anyone can decrypt your messages. 
  • Using one of the private signing keys, anyone can sign a message to send to your endpoint and your applications trusts it.
image-20231208154949-2 If you are using the WS-Security sample keys or certificates only when you run WS-Security sample configuration tasks in the IBM Documentation, you can find an interim fix that replaces the sample key stores at PH56482:WebSphere WS-Security sample keystores are expired .

Symptom

There are various errors that you might see in a trace file, SystemOut.log, or FFDC file.  An example is:
Exception: javax.xml.ws.soap.SOAPFaultException: java.security.PrivilegedActionException: com.ibm.wsspi.wssecurity.core.SoapSecurityException: security.wssecurity.WSSContextImpl.s02: com.ibm.websphere.security.WSSecurityException: Exception org.apache.axis2.AxisFault: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS5181E: The following certificate, which is owned by CN=SOAPRequester, OU=TRL, O=IBM, ST=Kanagawa, C=JP with the soaprequester alias from the c:\was90517\WebSphere\AppServer\profiles\guava/etc/ws-security/samples/dsig-sender.ks keystore, has expired: java.security.cert.CertificateExpiredException: NotAfter: Tue Aug 08 12:46:30 CDT 2023 ocurred while running action: com.ibm.ws.wssecurity.handler.WSSecurityGeneratorHandler$2@10737d36

Cause

The following keystores are delivered in WebSphere Application Server in the (PROFILE_ROOT)/etc/ws-security/samples directory.  The following certificates and keys in the keystores are expired:
Keystore
Keystore
Password
 Purpose Certificate Key
Key
Password
 Expiration
dsig-sender.ks client Signature soaprequester
client
 8/8/2023
soapca 8/7/2023
dsig-receiver.ks server Signature soapprovider server 8/8/2023
soapca 8/7/2023
enc-sender.jceks storepass Encryption bob keypass 8/7/2023
alice 8/7/2023
enc-receiver.jceks storepass Encryption alice
keypass
 8/7/2023
bob 8/7/2023
intca2.cer Signature 8/8/2023
  • keytool output for each keystore
    • dsig-sender.ks
      image-20230817141204-1
    • dsig-receiver.ks
      image-20230817141231-2
    • enc-sender.jceks
      image-20230811172403-1
    • enc-receiver.jceks
      image-20230811172500-2

Environment

This issue occurs with JAX-WS and JAX-RPC applications that use the WS-Security sample keystores. This issue also occurs for applications that self-issues SAML tokens by using the SAMLIssuerConfig.properties file.

Resolving The Problem

Although you can modify your bindings by using the administrative console or wsadmin, the solution in this document is to use a text editor to modify your binding.xml files.  Finding all the instances of the entries that you need to change by using the admin console or wsadmin is problematic and might not be the best solution in an emergency.
image-20231208154045-1 If you create new keystores, keys, and certificates with the same names and passwords as the WS-Security samples, both you and WebSphere support can no longer tell that your applications use the sample keystores in your configuration.  WebSphere support discourages matching your own keys and certificates to the samples.
  • This procedure is to create new keystores and keys, then replace the instances of the sample keystores, keys, and certificates in the JAX-WS general bindings that you use. 
  • This procedure does not address application-specific bindings, but the same replacement scheme can be used with application-specific bindings.
  • This procedure does not address JAX-RPC applications.
You can use the following procedure to modify each general binding that uses the WS-Security sample keystores:
  1. Create new keystores with self-signed keys and certificates for the client and provider.
    • Outline
      1. Create one keystore each for the client and the provider.
        1. Put the keystores in the (PROFILE_ROOT)/etc/ws-security directory
          • This path moves the keystores out of the samples directory, yet preserves the path in general so that extra steps are not required.
        2. Call the keystores sender.jks and receiver.jks
        3. Keystore type=JKS
        4. image-20230811040737-1 Set the two keystore passwords to the same value
          • The keystore passwords must be the same because enc-sender.ks and enc-receiver.ks have the same password.  If you don't use the same password, the procedure does not work as easily.  If you want to use different passwords, go back and change them later.
      2. Create a self-signed private key in each keystore.
        • image-20230811040737-1 Set the key passwords to the same value as the keystore passwords.
        • Key size=1024
        • Signature Algorithm=SHA1WithRSA
        • In sender.jks, call the key client
        • In receiver.jks, call the key server
      3. Exchange the certificates between the keystores:
        1. Export the certificate for each key.
        2. Import the server's certificate into sender.jks with alias=server
        3. Import the client's certificate into receiver.jks with alias=client
    • Create the keystores and keys by using the keytool utility
      1. Open a command window
        • You can find the keytool utility in the JAVA_HOME/bin directory. 
      2. Create your signing keys:
        keytool -genkey -alias client -dname "CN=client" -keystore sender.jks -storepass YOUR_STOREPASS -keypass YOUR_STOREPASS -keyalg RSA -sigalg SHA1withRSA -validity 20000 -storetype jks
        keytool -genkey -alias server -dname "CN=server" -keystore receiver.jks -storepass YOUR_STOREPASS -keypass YOUR_STOREPASS -keyalg RSA -sigalg SHA1withRSA -validity 20000 -storetype jks
         
        • You can ignore this warning if you get it:
          Warning:
          The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore sender.jks -destkeystore sender.jks -deststoretype pkcs12"
      3. Exchange the certificates:
        keytool -export -keystore sender.jks -storepass YOUR_STOREPASS -alias client -file client.cer
        keytool -export -keystore receiver.jks -storepass YOUR_STOREPASS -alias server -file server.cer
        keytool -import -keystore sender.jks -storepass YOUR_STOREPASS -alias server -file server.cer -noprompt
        keytool -import -keystore receiver.jks -storepass YOUR_STOREPASS -alias client -file client.cer -noprompt
        • You can ignore this warning if you get it:
          Warning:
          The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
          The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore receiver.jks -destkeystore receiver.jks -deststoretype pkcs12".
    • Create the keystores and keys by using iKeyman and keytool
      1. Start iKeyman
      2. Click Key Database File > New
        • Key database type: JKS
        • File name: sender.jks
        • Location: any location that you can find later
        • image-20230811040737-1 Password: pick a password and note it for use later. Use the same password for each file. You use this password for every password in this task.
      3. Click OK
      4. Click Create > New Self-Signed Certificate
        • Key label: client
        • Validity Period: 10950 (30 years)
        • You can enter anything you want for the optional fields.
        • image-20230811021406-1 Do not change the values for Key Size or Signature Algorithm
      5. Click OK
      6. Click Key Database File > New
        • Key database type: JKS
        • File name: receiver.jks
        • Location: any location that you can find later
        • image-20230811040737-1 Password: use the same password that you did for sender.jks
      7. Click OK
      8. Click Create > New Self-Signed Certificate
        • Key label: server
        • Validity Period: 10950 (30 years)
        • You can enter anything you want for the optional fields.
        • image-20230811021406-1 Do not change the values for Key Size or Signature Algorithm
      9. Click OK
      10. Quit iKeyman 
        • image-20230811040737-1 iKeyman assigns the keystore password to the keys
      11. Exchange the certificates for the keys between the two keystores:
        1. Open a command window.
        2. Change directory to the directory where you put the keystores.
        3. Exchange the certificates by using the following keytool commands:
          keytool -export -keystore sender.jks -storepass YOUR_STOREPASS -alias client -file client.cer
          keytool -export -keystore receiver.jks -storepass YOUR_STOREPASS -alias server -file server.cer
          keytool -import -keystore sender.jks -storepass YOUR_STOREPASS -alias server -file server.cer -noprompt
          keytool -import -keystore receiver.jks -storepass YOUR_STOREPASS -alias client -file client.cer -noprompt
           
          • You can find the keytool utility in the JAVA_HOME/bin directory.
          • You can find information about using keytool utility in the Keytool topic in the IBM Documentation.
  2. Make sure that your two new keystore files, sender.jks and receiver.jks, are in the (PROFILE_ROOT)/etc/ws-security directory.
  3. For each general binding that is attached to an application or endpoint that also uses the sample keystores, perform the following actions:
    1. In the administrative console or wsadmin, make a backup copy of the binding that you are changing.
      • wsadmin examples:
        AdminTask.copyBinding('[-sourceBinding "Client sample" -newBinding CLIENT_SAMPLE_BACKUP]')
        AdminConfig.save()
        • Alternatively, if you want to maintain your old binding and modify the new one instead, you can run the following example command.  This command automatically attaches all applications that were attached to the old binding to your new one.
          AdminTask.copyBinding('[-sourceBinding "Client sample" -newBinding NEW_CLIENT_GENERAL_BINDING -transferAttachments true]')
          AdminConfig.save()
    2. Make sure that all configuration changes are stopped.
      • If you are logged in to the administrative console, log out.
      • Exit wsadmin if it is active.
    3. Open the following file in an editor: 
      (PROFILE_ROOT)\config\cells\(CELL_NAME)\bindings\(BINDING_NAME)\PolicyTypes\WSSecurity\bindings.xml
      • image-20230811040737-1 If your target profile is a managed node, perform the bindings.xml file updates in the deployment manager profile.
      • Make the following global replacements to the file:
        Original text New text Comment
        samples/dsig-receiver.ks receiver.jks New provider keystore
        samples/enc-receiver.jceks receiver.jks
        samples/dsig-sender.ks sender.jks New client keystore
        samples/enc-sender.jceks sender.jks
        JCEKS JKS
        {xor}LDotKTot NEW PASSWORD
        If you want to replace with XOR encoded instead of plain text, XOR encode the password before you do the text replacement.
        {xor}PDM2OjEr NEW PASSWORD
        {xor}LCswLTovPiws NEW PASSWORD
        {xor}NDomLz4sLA== NEW PASSWORD
        CN=SOAPProvider, OU=TRL, O=IBM, ST=Kanagawa, C=JP server The values for the next four DNs don't matter to the runtime, but they must have values.  Don't worry about matching them to the DNs that you chose for your keys.
        CN=Bob, O=IBM, C=US server
        CN=SOAPRequester, OU=TRL, O=IBM, ST=Kanagawa, C=JP client
        CN=Alice, O=IBM, C=US client
        soapprovider server Signing key
        bob server Encrypting key and decrypting certificate
        soaprequester client Signing key
        alice client Encrypting key and decrypting certificate
    4. Save the changes
  4. If you have applications that self-issue SAML tokens, edit the SAMLIssuerConfig.properties file:
    1. Open the following file in an editor:
      (PROFILE_ROOT)\config\cells\(CELL_NAME)\sts\SAMLIssuerConfig.properties
    2. Make the following global replacements to the file:
      Original text New text Comment
      samples/dsig-receiver.ks receiver.jks New provider keystore
      {xor}LDotKTot NEW PASSWORD If you want to replace with XOR encoded instead of plain text, XOR encode the password before you do the text replacement.
      CN=SOAPProvider, OU=TRL, O=IBM, ST=Kanagawa, C=JP server The value for this DN doesn't matter to the runtime, but it must have a value.  Don't worry about matching it to the DN that you chose for your key.
      soapprovider server Signing key
    3. Save the changes
  5. If you made changes to a deployment manager profile, synchronize your nodes.
    • Synchronizing the nodes only synchronizes your updates to the bindings.xml  and SAMLIssuerConfig.properties files.  It does not synchronize the following directory:
      • (PROFILE_ROOT)/etc
  6. If the partner is in a different profile, copy the appropriate new keystore to the partner profile.
    • You create one set of keystores for all profiles, then make sure all affected bindings in all profiles to match the new keystores.
  7. Restart the server.
  8. Test your application

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CcyRAAS","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003EWeb Services Security"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
08 December 2023

UID

ibm17025379

Page Feedback