Resolving "Failed to establish chain from reply" and Keystore Import Errors in LiveUpdate Administrator (LUA) when replacing a certificate

Products

• Endpoint Protection

Issue/Introduction

When following KB 171754 to replace the LUA web server SSL certificate, Step 3 fails during certificate import with one of the following errors:

Primary Error: keytool error: java.lang.Exception: Failed to establish chain from reply

Secondary Error: keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

Environment

LiveUpdate Administrator (LUA) 2.3.x and newer

Cause

1. Causes for "Failed to establish chain from reply"

This error occurs when keytool cannot build an unbroken path from your signed leaf certificate up to a trusted Root CA in the keystore:

• Missing Sub-CA / Issuing CA: Internal enterprise CAs frequently use multi-tier hierarchies. If an Issuing CA exists below the Intermediate CA and was not imported prior to the leaf certificate, the chain breaks.

• Alias Mismatch: The final -import command used a different -alias name than the one used during -genkeypair (CSR generation). keytool treats a non-matching alias as a new trusted certificate entry instead of a response to your private key.

• Public Key Mismatch: The signed certificate was issued against a different CSR, or the keystore was regenerated after the CSR was sent to the CA.

2. Causes for "Keystore was tampered with, or password was incorrect"

This generic exception is thrown whenever keytool fails to open or parse the keystore file:

• PowerShell Special Character Escaping: Special characters in the password (e.g., $, `, ", !, &) are stripped or interpreted as variables by PowerShell before reaching keytool.

• JRE Path & Keystore Type Mismatch: Windows environment %PATH% may execute a system-wide Java JRE (JDK 9+ defaults to PKCS12) instead of LUA's bundled JRE (which uses JKS). Opening a JKS file with PKCS12 rules triggers this password error.

Resolution

1. Resolution for "Failed to establish chain from reply"

Import every tier of the CA hierarchy in sequential order from top to bottom before importing the signed leaf certificate:

 

:: 1. Import Root CA
"C:\Program Files (x86)\Symantec\LiveUpdate Administrator\jre\bin\keytool" -import -alias root -trustcacerts -storetype jks -file c:\windows\temp\root.cer -keystore c:\windows\temp\newcert.jks

:: 2. Import Policy / Intermediate CA
"C:\Program Files (x86)\Symantec\LiveUpdate Administrator\jre\bin\keytool" -import -alias intermediate -trustcacerts -storetype jks -file c:\windows\temp\intermediate.cer -keystore c:\windows\temp\newcert.jks

:: 3. Import Sub-CA / Issuing CA
"C:\Program Files (x86)\Symantec\LiveUpdate Administrator\jre\bin\keytool" -import -alias issuing -trustcacerts -storetype jks -file c:\windows\temp\issuing.cer -keystore c:\windows\temp\newcert.jks

:: 4. Import Signed Leaf Certificate
"C:\Program Files (x86)\Symantec\LiveUpdate Administrator\jre\bin\keytool" -import -alias lua.mydomain.local -trustcacerts -storetype jks -file c:\windows\temp\signedcert.cer -keystore c:\windows\temp\newcert.jks

Note: Type yes when prompted to trust the Root CA. Intermediate and Issuing CAs will be trusted automatically without a prompt once the Root CA is present.

2. Resolution for "Keystore was tampered with, or password was incorrect"

1. Always append -storetype jks to every command.

2. Handle Special Characters in password (e.g., $, `, ", !, &)

 

Additional Information

Verify that the private key exists and note its exact alias:
"C:\Program Files (x86)\Symantec\LiveUpdate Administrator\jre\bin\keytool" -list -v -keystore c:\windows\temp\newcert.jks -storetype jks

Additional checks:

Verification Check	Required Result
Entry type	PrivateKeyEntry	Confirms the response bound to your original secret key.
Certificate chain length*	3 or 4	Proves the Root, Intermediate, and Issuing CAs are linked.
Issuer	CN=Your Issuing CA Name	Confirms the leaf matches the bottom-tier CA in your hierarchy.

*depending on the length of the chain