Liberty 20.0.0.3 Docker数据源加密密码无法生效问题

Let’s break down why your encrypted password isn’t working (while plaintext does) and walk through fixes for the $ symbol issue, plus how to check code page compatibility in your Docker terminal.

Core Issue: The $ Symbol in Your Password #

The biggest red flag here is the $$ in your password. When you run securityUtility encode in a Docker terminal, the shell interprets $ as a special character—$$ gets replaced with the current process ID, meaning you’re actually encrypting a different password than you intended! That’s why Liberty can’t decrypt it to authenticate with SQL Server.

Step 1: Correctly Encrypt the Password with $ #

To prevent the shell from mangling your password, wrap it in single quotes when running the encode command. This tells the shell to treat the password as a literal string:

securityUtility encode --encoding=aes 'mypa$$word'

Alternatively, you can escape each $ with a backslash:

securityUtility encode --encoding=aes mypa\$\$word

Verify the encryption: Use the decode command to double-check the encrypted string resolves to your original password:

securityUtility decode {aes}ADPrOj1GfH/9Am3TSqT7MLN0+sRPkXHUAy7RIk+dbRmZR0fEQTEkzHv1lDTnGhGeaA==

If the output isn’t mypa$$word, re-encrypt with the quoted/escaped command.

Step 2: Ensure Encryption Key Consistency in Docker #

Liberty uses a unique bootstrap.key file (stored in ${server.config.dir}/resources/security) to encrypt/decrypt passwords. If you encrypted the password outside the Docker container, the key won’t match the one inside your Liberty container—this guarantees decryption fails.

Always run the securityUtility encode command inside your running Liberty container:

1. Enter the container shell:

   docker exec -it <your-liberty-container-id> /bin/bash
   

2. Navigate to Liberty’s bin directory (usually /opt/ibm/wlp/bin):

   cd /opt/ibm/wlp/bin
   

3. Run the corrected encode command from Step 1, then copy the output into your server.xml or bootstrap.properties.

Fixes for Your Three Configuration Approaches #

Let’s adjust each of your attempted configurations to work with the properly encrypted password:

1. Direct properties Configuration #

Ensure the encrypted password (generated correctly in-container) is pasted exactly into the password attribute:

<dataSource id="DS1" jndiName="jdbc/DS1" transactional="true">
  <jdbcDriver libraryRef="MSSQL"/>
  <properties.microsoft.sqlserver 
    serverName="myserver" 
    instanceName="myinstance" 
    databaseName="mydatabase" 
    user="myuser" 
    password="{aes}YOUR_CORRECTLY_ENCRYPTED_PASSWORD_HERE" />
</dataSource>

2. containerAuthData Configuration #

When using containerAuthData, make sure you’re not conflicting with properties, and the encrypted password is valid. The "Login failed for user ''" error suggests Liberty couldn’t decrypt the password to read the user, so double-check the encrypted string:

<dataSource id="DS1" jndiName="jdbc/DS1" transactional="true">
  <jdbcDriver libraryRef="MSSQL"/>
  <containerAuthData user="myuser" password="{aes}YOUR_CORRECTLY_ENCRYPTED_PASSWORD_HERE" />
  <properties.microsoft.sqlserver 
    serverName="myserver" 
    instanceName="myinstance" 
    databaseName="mydatabase" />
</dataSource>

3. bootstrap.properties Variable Reference #

Confirm bootstrap.properties is in the correct location (${server.config.dir}, typically /config in Liberty Docker images) and the pwd value is the properly encrypted password:

# bootstrap.properties
pwd={aes}YOUR_CORRECTLY_ENCRYPTED_PASSWORD_HERE

Then reference it in server.xml as before:

<dataSource id="DS1" jndiName="jdbc/DS1" transactional="true">
  <jdbcDriver libraryRef="MSSQL"/>
  <properties.microsoft.sqlserver 
    serverName="myserver" 
    instanceName="myinstance" 
    databaseName="mydatabase" 
    user="myuser" 
    password="${pwd}" />
</dataSource>

Checking Code Page Compatibility in Docker Terminal #

To verify your terminal’s character encoding isn’t causing issues (though $ is ASCII, this is good practice):

1. Check the current locale and encoding with:

   locale
   

   Look for LC_CTYPE set to en_US.UTF-8 (or another UTF-8 variant)—this is the standard for handling special characters correctly.
2. Test if the shell preserves your password’s literal value:

   echo 'mypa$$word'
   

   If the output is exactly mypa$$word, your shell isn’t mangling the string. If it shows something like mypa1234word (where 1234 is a process ID), you need to use the quoted/escaped approach from Step 1.

Additional Debugging #

If you still hit issues, enable Liberty’s debug logging to see what’s happening during decryption:
Add this to your server.xml to log security and JDBC details:

<logging traceSpecification="com.ibm.ws.security.*=all:com.ibm.ws.jdbc.*=all"/>

Check the logs in /logs/trace.log inside the container—look for errors related to password decryption or authentication.

内容的提问来源于stack exchange，提问作者user1421324