AutoUpgrade and Transparent Data Encryption (TDE)

It is now easier to upgrade and convert your encrypted Oracle Database. The latest version of AutoUpgrade adds much better support for Oracle Databases that are encrypted with Transparent Data Encryption (TDE).

You must ensure that you are using the latest version of AutoUpgrade. You can download it from My Oracle Support AutoUpgrade Tool (Doc ID 2485457.1). At the time of writing, the latest version of AutoUpgrade is 22.2:

$ java -jar autoupgrade.jar -version
build.version 22.2.220324

AutoUpgrade Keystore

Dealing with TDE, also means dealing with sensitive information. AutoUpgrade must adequately protect the TDE keystore passwords. To do so, AutoUpgrade can have its own keystore to store sensitive information, i.e., TDE keystore passwords. Whenever a TDE keystore password is needed, e.g., during an unplug-plug upgrade of an encrypted PDB, it can get the password from the AutoUpgrade keystore.

You need to tell AutoUpgrade where it can create the keystore. You do so in the config file:

global.keystore=/etc/oracle/keystores/autoupgrade/DB12

When you start to use the AutoUpgrade keystore the following files are created in the directory:

$ pwd
/etc/oracle/keystores/autoupgrade/DB12

$ ll
-rw-------. 1 oracle dba 765 Mar 28 14:56 cwallet.sso
-rw-------. 1 oracle dba 720 Mar 28 14:56 ewallet.p12

It is similar to other keystores that Oracle Database use. ewallet.p12 is the keystore, and cwallet.sso is an auto-login keystore used to open the real keystore. You don’t have to create an auto-login keystore.

You should protect the AutoUpgrade keystore files like you protect any other Oracle Database keystore:

  • Apply restrictive file system permissions.
  • Audit access.
  • Back it up.

Using the Keystore

Create your AutoUpgrade config file and specify global.keystore as described above. Start an interactive prompt that allows you to add the necessary passwords:

$ java -jar autoupgrade.jar -config DB12.cfg -load_password

The first time you use the AutoUpgrade keystore, you must provide a password that protects the AutoUpgrade keystore:

Starting AutoUpgrade Password Loader - Type help for available options
Creating new keystore - Password required
Enter password:       
Enter password again: 
Keystore was successfully created

In the TDE console, the following commands are available:

  • add
  • delete
  • list
  • save
  • help
  • exit

The SID references the databases. If you want to add a TDE password for the database DB12, use the following command:

TDE> add DB12
Enter your secret/Password:    
Re-enter your secret/Password: 
TDE> add CDB2
Enter your secret/Password:    
Re-enter your secret/Password: 

If you want to delete the TDE password for DB12:

TDE> delete DB12

Keystore Password is required prior to operation
Enter wallet password:   

When you save the passwords into the AutoUpgrade keystore, you must decide whether you want to have an auto-login keystore:

TDE> save
Convert the keystore to auto-login [YES|NO] ? 

I recommend using auto-login keystores. If you do not create an AutoUpgrade auto-login keystore, you will be prompted for the AutoUpgrade keystore password when you start AutoUpgrade. If you want to use AutoUpgrade in noconsole mode (-noconsole), then an auto-login keystore is required.

I will show how to upgrade and convert encrypted databases in later blog posts.

Loss of AutoUpgrade Keystore

What happens if your AutoUpgrade keystore is lost? This is fairly simple. You can re-create the keystore and load all passwords into it using the load_password command line option as described above.

Preupgrade Checks

We have added new preupgrade checks to the analyze phase in AutoUpgrade. These checks will help you to provide the needed passwords and ensure your TDE configuration meets certain standards:

  • auto_login_keystore_required
  • keystore_conflict
  • no_keystore_files
  • tde_passwords_required
  • wallet_root
  • tde_in_use
  • oracle_home_keystore

You can read more about these checks in MOS note Database Preupgrade tool check list. (Doc ID 2380601.1).

Further Reading

Other Blog Posts in This Series

7 thoughts on “AutoUpgrade and Transparent Data Encryption (TDE)

  1. Does the load-password feature work with 12.1.0.2 databases? I cannot get it too load the wallet password for a 12.1 CDB.When adding the password for the 12.1.0.2. database the action remains as load password wallet.

    TDE> list
    +———-+——————–+————+———–+——————+
    |ORACLE_SID| Action Required|TDE Password|SEPS Status|Active Wallet Type|
    +———-+——————–+————+———–+——————+
    | cdbvj01|Load password wallet| Unknown| Inactive| Password|
    | cdbvj191| | Verified| Inactive| Any|
    +———-+——————–+————+———–+——————+

    Like

  2. Hi Adeem,

    Yes, the feature should work for any version supported by AutoUpgrade – which is the case with 12.1.0.2. What exactly are you trying to do? I think it could be an unplug-plug upgrade from 12.1.0.2 to 19c. Is that correct?

    Regards,
    Daniel

    Like

  3. autotoupgrade is definitely an awesome tool for Oracle DB upgrade.
    I successfully played with it on a configuration having primary 12.2.0.1 rac 2 nodes and standby rac 2 nodes with TDE (wallet on file system).
    Unfortunately it didn’t work when the wallet files were in ASM (either for source 12.2 or target 19c): autoupgrade always failed to copy the wallet files.
    Is there a plan to have autoupgrade successfully work with TDE files located in ASM instead of files system?

    Thanks.

    Like

  4. Hi Sylvian,

    Thanks for the positive feedback. It’s good to hear you like AutoUpgrade. We put a lot of hard work in it.

    I am not aware about any restrictions with the TDE keystore on ASM. Do you have a SR with this error? If not, may I ask you to create one. Be sure to attach the log files from the error (java -jar autoupgrade.jar -config …. -zip). I will have one of the developers look at the problem, so we can get it sorted.

    Thanks,
    Daniel

    Like

  5. Hi, is Autoupgrade with TDE only possible for in place upgrade (same server)? Are there any ways to do it for out of place (new db home in a different server) with autoupgrade? It seems like the target_home have to be specified.

    Like

Leave a comment