summaryrefslogtreecommitdiffstats
path: root/base/java-tools
diff options
context:
space:
mode:
authorAde Lee <alee@redhat.com>2017-03-28 13:01:30 -0400
committerAde Lee <alee@redhat.com>2017-03-28 14:18:14 -0400
commita5cbfd0fcd966604a5188352bb09042e3132eb32 (patch)
treec8c8f4a44363860149d604a0b45d8e78da53f06b /base/java-tools
parent358064eed09fd43e9fe7b08e43bd03775df880df (diff)
downloadpki-a5cbfd0fcd966604a5188352bb09042e3132eb32.tar.gz
pki-a5cbfd0fcd966604a5188352bb09042e3132eb32.tar.xz
pki-a5cbfd0fcd966604a5188352bb09042e3132eb32.zip
Fix retrieval for symmetric keys
Up to now, we have only ever used the same algorithm (DES3_CBC) for key wrapping and encryption. With the change to use AES Keywrap and AES CBC, we need to know which mechanism was used to encrypt/wrap the secrets when returned to the client. This means passing back more information to the client with the key data, and also modifying the client to use this information to decode the data correctly. Change-Id: I7232085c1eedf38c63abad81db08acc912fa1da1
Diffstat (limited to 'base/java-tools')
-rw-r--r--base/java-tools/src/com/netscape/cmstools/CRMFPopClient.java2
1 files changed, 1 insertions, 1 deletions
diff --git a/base/java-tools/src/com/netscape/cmstools/CRMFPopClient.java b/base/java-tools/src/com/netscape/cmstools/CRMFPopClient.java
index fafe956e7..901528c2f 100644
--- a/base/java-tools/src/com/netscape/cmstools/CRMFPopClient.java
+++ b/base/java-tools/src/com/netscape/cmstools/CRMFPopClient.java
@@ -554,7 +554,7 @@ public class CRMFPopClient {
EncryptionAlgorithm encryptAlg = null;
String keyset = System.getenv("KEY_WRAP_PARAMETER_SET");
- if ((keyset != null) && (keyset.equalsIgnoreCase("0"))) {
+ if (keyset != null && keyset.equalsIgnoreCase("0")) {
// talking to an old server?
encryptAlg = EncryptionAlgorithm.DES3_CBC;
} else {