Resetting encryption keys

[Ujwol]

This is for @P Soni

This is continuation of : SSO between SiteMinder r12.0 SP3 to r12.7 SP2 policy server in parallel upgrade 

 

On the other hand, in another environment, we came to find that the enc. keys are different.

In this env., we have 2 policy-servers. I have reset the enc. keys on one policy-server(12.7 as it was on 12.0) by following the other link posted by you.

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/administrating/manage-encryption-keys/reset-the-r12-x-policy-store-encryption-key

Unfortunately, I didn't run smreg command on the other policy-server. So one policy-server enc keys are changed and 2nd PS still hasn't have the re-changed keys.

Please let me know what steps I should perform on the second Policy-server. Do I have to re-do all the steps that I did for the first PS?

[Ujwol]

So my understanding is :

 

Two policy server P1 & P2 connecting to common policy store and key store.

 

You followed all the steps mentioned here on P1:

 

1. Log into the Policy Server.

2. Stop the Policy Server.

   Note: Stop all Policy Servers pointing to the policy store before changing the encryption key.

3. Export a full-backup of the policy store contents in clear text using XPSExport.

   xpsexport [set the File Name variable] -xb –npass
   or (for encrypted output)
   xpsexport [set the File Name variable] -xb –pass <password>

4. Export the Agent Keys using smkeyexport (clear-text option is required).

   smkeyexport –o [set the File Name variable] -d<sm admin name> -w<smadmin password> -c

5. Change the policy store encryption key using the smreg command.

   smreg –key <new key>

6. Reset and test the policy store password using SmConsole. Use the "Data" tab of SmConsole to re-enter the previously configured password, apply the change and then use the "Test Connection" button to verify.

7. Import the policy store contents using XPSImport using export taken in Step 3.

   xpsimport [set the File Name variable] –fo –pass <password>
   or (if no password was used to create the export file):
   xpsimport [set the File Name variable] –fo –npass

8. Import the Agent Keys using smkeyimport (clear-text option) using export taken in Step 4.

   smkeyimport –i[set the File Name variable] -d<sm admin name> -w<sm admin password> -c

9. Restart the Policy Server.

 

But you haven't run the smreg command on the P2 policy server.

 

Next Action :

 

1. If that is correct understanding, could you just try to copy the EncryptionKey.txt from P1 to P2.
2. Provide the credentials in the smconsole for policy store/keystore/audit/session etc and make sure it works.

 

 

VERIFY P1 and P2 are usign same encrypiton key :

 

 

Try performing a clear text export of keys using following command from P2 :

smkeyexport -d<admin> -w<password> -okeys.txt -c

 

If the keys are in clear text with no {RC2} or {AES} prefix then it will conclude enryption keys in P1 and P2 are in sync.

[P Soni]

Hi Ujwol,

 

I really appreciate your quick response. I was able to change the keys on 2nd policy-server with the steps mentioned by you. The export worked in clear text.

One error message appearing in the log though:

[][CServer.cpp:2293][ERROR][sm-Server-01070] Failed handshake with IP.
[][][CServer.cpp:2121][ERROR][sm-Tunnel-00010] Bad security handshake attempt. Handshake error: 3154

 

The 2nd policy-server where I had changed the Enc keys by replacing the Enc.txt file, is showing handshake errors with adminui. After seeing these errors, I had re-registered this 2nd policy-server to adminui using below command without the -setup option:

./XPSRegClient clientname:passphrase -adminui -vT

I was able to register this PS and add this PS in admin-ui successfully as a secondary PS.

 

I am still seeing the errors in smps.log. It looks like I will have to do some cleanup in terms of deleting old trusted host that got registered previously?

Thanks again for all your help!

[Ujwol]

No worries. You should not be getting handshake error in only one PS if its a common policy store.

There are few types of handshake errors:

https://comm.support.ca.com/kb/what-are-the-possible-handshake-errors-in-policy-server/kb000042071

This should give you some hint.

I would find out the problematic client which is failing to handshake and try to identify why it is failing.