I am looking to "migrateIn" a policy and was able to successfully at one time. When I instantiated a new instance of API Gateway I could no longer import the policy. The messages I receive during migrateIn are:
Warning: TLS hostname verification has been disabled
Execution failed. Reason: Migrate in failed: Bad Request Resource validation failed due to 'INVALID_VALUES' The user encrypted password in not valid. Message: Unable to decrypt password: bad mac value
When I use the old password and encryptionPassphrase from the previous server the policy imports (currently those 2 server instances match). Why is
GatewayMigrationUtility.sh encodePassword --password some_password --hideProgress
failing to generate an understandable encryption...or why is the new API Gateway instance unable to decrypt it?
How do I correct it?
I am using API Gateway 9.1 and GatewayMigrationUtility 1.3.00. I think it might be possible I used GatewayMigrationUtility 1.2.00 to generate the original/functional password and encryptionPassphrase, but doesn't seem to help if I use the old version.
The encryption passphrase is a separate password from everything. It is used on the migrateOut to encrypt the bundle file. You must use the encryption passphrase that was used on the migrateOut on the migrateIn to decrypt the bundle file. The "password" would be the administrator username/password used in order to connect to your gateway. The same one you would typically use to connect to the gateway with policy manager. This can be different from environment to environment.
Just to verify, if i migrate out and my passphrase is "hello_world" and i encrypt it and it becomes "@#@#".
If I go to import it and re-run the encryption on the same "hello_world" and it becomes "AAAA", it should still work, right?
Thanks for the clarification.
Nevermind, re-read https://docops.ca.com/ca-api-gateway/9-0/upgrade-migrate-patch-back-up-restore/migrate-gateways/gateway-migration-exampl…
Looks like the same encryption file is used in both places. So it must be the exact same encrypted_passphrase.
You are correct