cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5248
Views
12
Helpful
7
Replies

ISE RESTORE ERROR - WRONG ENCRYPTION KEY OR CORRUPTED DOWNLOAD

kajibola
Level 1
Level 1

We have an issue regarding ACS to ISE migration and I don't know if you ve encountered it before.

Back-up was done from production ACS 5.8 patch 6 and imported to the LAB/migration ACS 5.8 patch 6. Migration tool was used to migrate config from the migration/lab ACS 5.8 patch 6 to migration/lab ISE 2.3 patch 3. After then back-up was done on migration/ISE lab, we tried restoring the back-up from the lab ISE to the newly deployed ISE but it keeps giving us "wrong encryption key or corrupted download from repository".

We are very sure the encryption key is correct. Backup file have been re-generated and re-downloaded thrice with no success in restoring it to the newly deployed ISE.

Note: The migration/lab ISE is running ISE 2.3 patch 3 which is same with the newly deployed ISE.

I tried doing a backup and restore from the same newly deployed ISE to itself and it works but back up from the LAB ISE to the newly deployed ISE for restoration is not working.

Any pointer?

encry.JPG

1 Accepted Solution

Accepted Solutions

kthiruve
Cisco Employee
Cisco Employee

Hi Kusimo,

Also something to remember is that you dont know how many backups and restores was done prior to ACS 5.8 p6 to get to that version. As Arne pointed out it could be corruption from ftp as well.

You can isolate this by taking existing backup(first backup), resetting the ISE config, take a fresh backup and restore it to another ISE server. There by you are avoiding the corruption carried over if any.

Try restoring the first backup to the same ISE server and see if it comes up avoiding ftp. You can create a local repository for backup. Also for sanity sake I have to say this, make sure you are using the right repository and right file etc...:)

Would be good to call TAC to troubleshoot further if it impacts your business.

Thanks

Krishnan

View solution in original post

7 Replies 7

Arne Bier
VIP
VIP

Just as a sanity check, copy that tar.gpg file to a Linux server and then use the gpg command to test your decryption key

[abier@centos ~]$ gpg -v --batch --yes --passphrase badphrase -d /mnt/hgfs/D/tmp/ISEDailyConfigBackups-CFG10-180524-0300.tar.gpg  > /dev/null

gpg: AES encrypted data

gpg: encrypted with 1 passphrase

gpg: decryption failed: Bad session key

Below is an example of the correct key (I replaced the password with *'s)

[abier@centos ~]$ gpg -v --batch --yes --passphrase *********  -d /mnt/hgfs/D/tmp/ISEDailyConfigBackups-CFG10-180524-0300.tar.gpg  > /dev/null

gpg: AES encrypted data

gpg: encrypted with 1 passphrase

gpg: original file name='ISEDailyConfigBackups-CFG10-180524-0300.tar'

[abier@centos ~]$

@Arne,

user@ubuntu:~/Desktop$ gpg -v --batch --yes --passphrase correctkey -d UNON_REMOTE_BACKUP-CFG10-180523-0816.tar.gpg > /dev/null

gpg: AES encrypted data

gpg: encrypted with 1 passphrase

gpg: original file name='UNON_REMOTE_BACKUP-CFG10-180523-0816.tar'

gpg: WARNING: encrypted message has been manipulated!

user@ubuntu:~/Desktop$

user@ubuntu:~/Desktop$ gpg -v --batch --yes --passphrase incorrectkey -d UNON_REMOTE_BACKUP-CFG10-180523-0816.tar.gpg > /dev/null

gpg: AES encrypted data

gpg: encrypted with 1 passphrase

gpg: decryption failed: Bad session key

Not seen that before.  I would speculate that ISE 2.0 signed that backup with an older cipher or something

Try the -vv argument for more verbose output - maybe it spits out a useful clue in your case

[abier@centos ~]$ gpg -vv --batch --yes --passphrase ****** -d /mnt/hgfs/D/tmp/ISEDailyConfigBackups-CFG10-180524-0300.tar.gpg  > /dev/null

:symkey enc packet: version 4, cipher 7, s2k 3, hash 2

salt 7c73b46bc89be249, count 8912896 (209)

gpg: AES encrypted data

:encrypted data packet:

length: 399761931

mdc_method: 2

gpg: encrypted with 1 passphrase

:literal data packet:

mode b (62), created 1527095724, name="ISEDailyConfigBackups-CFG10-180524-0300.tar",

raw data: 399761836 bytes

gpg: original file name='ISEDailyConfigBackups-CFG10-180524-0300.tar'

gpg: decryption okay

ISE 2.3 patch 3 was used

user@ubuntu:~/Desktop$ gpg -vv --batch --yes --passphrase **** -d UNON_REMOTE_BACKUP-CFG10-180523-0816.tar.gpg > /dev/null

# off=0 ctb=8c tag=3 hlen=2 plen=13

:symkey enc packet: version 4, cipher 7, s2k 3, hash 2

salt 0CD78ED18AD3030F, count 8126464 (207)

gpg: AES encrypted data

# off=15 ctb=d2 tag=18 hlen=6 plen=56938060 new-ctb

:encrypted data packet:

length: 56938060

mdc_method: 2

gpg: encrypted with 1 passphrase

# off=40 ctb=ae tag=11 hlen=5 plen=56938014

:literal data packet:

mode b (62), created 1527064416, name="UNON_REMOTE_BACKUP-CFG10-180523-0816.tar",

raw data: 56937968 bytes

gpg: original file name='UNON_REMOTE_BACKUP-CFG10-180523-0816.tar'

gpg: WARNING: encrypted message has been manipulated!

Funny enough, my example backup file was also taken on ISE 2.3 patch 3!

The only difference I can see is the gpg stuff

# off=0 ctb=8c tag=3 hlen=2 plen=13

# off=15 ctb=d2 tag=18 hlen=6 plen=56938060 new-ctb

I don't know what that means.  These gpg files are binary - what are the chances that you inadvertently ftp'd/transferred the file in ASCII mode and not BINARY?  It's a long shot but worth checking

kthiruve
Cisco Employee
Cisco Employee

Hi Kusimo,

Also something to remember is that you dont know how many backups and restores was done prior to ACS 5.8 p6 to get to that version. As Arne pointed out it could be corruption from ftp as well.

You can isolate this by taking existing backup(first backup), resetting the ISE config, take a fresh backup and restore it to another ISE server. There by you are avoiding the corruption carried over if any.

Try restoring the first backup to the same ISE server and see if it comes up avoiding ftp. You can create a local repository for backup. Also for sanity sake I have to say this, make sure you are using the right repository and right file etc...:)

Would be good to call TAC to troubleshoot further if it impacts your business.

Thanks

Krishnan

kajibola
Level 1
Level 1

Thank you all for the wonderful contributions.

Doing checksum on the file and the remote one shows that the hash is no longer the same. Re-uploading and re-downloading it is not even helping as we are still having the encryption key issue.

Back up generated and restored on the newly deployed ISE is working without encryption key error.

I decide to do my own migration locally and this solves the problem.