1. Administrator's Guide
  2. Getting Started with Oracle Audit Vault and Database Firewall
  3. General Security Guidelines

3 General Security Guidelines

Learn about general security guidelines for Oracle Audit Vault and Database Firewall.

3.1 Installing Oracle Audit Vault and Database Firewall Securely to Protect Your Data

Learn how to securely install Oracle AVDF to protect your data.

3.1.1 Installing Oracle Audit Vault and Database Firewall Securely

Learn to securely install Oracle Audit Vault and Database Firewall.

Oracle Audit Vault Server installs in a secure state by default. Therefore, it is important to be careful if you change any of the default settings because your changes may compromise the security of your setup.

See Also:

Oracle Audit Vault and Database Firewall Installation Guide for details of the installation.

3.1.2 Protecting Your Data

Consider account naming, password use, and other guidelines to better enable Oracle AVDF to protect your data.

Consider following these guidelines to protect your data:

  • Account Names and Passwords: Use secure passwords for the Oracle Audit Vault Server console UI, as well as for the root, support, and sys accounts and keep these passwords safe.

  • Administrator Accounts: Do not share Oracle Audit Vault and Database Firewall Administrator accounts.

  • Strong Password Policies: Encourage users to adopt strong passwords.

  • Installed Accounts: Oracle Audit Vault and Database Firewall embeds operating system and database accounts. Do not add new accounts of this type. Do not unlock the existing accounts. Doing so may compromise the security of the Oracle Audit Vault and Database Firewall system.

  • Secure Archiving: Oracle Audit Vault and Database Firewall sends archive data over the network. Secure both the archive destination and intermediate network infrastructure.

  • Remote Access: The Settings tab of the services page of Oracle Audit Vault Server console controls access to:
    • web console
    • shell (ssh)
    • SNMP

    Follow these guidelines when granting remote access:

    • Grant access only if you need it for a specific task and then revoke access when that task is completed.

    • Restrict access by IP address. Do this immediately after installing the system.

    • Grant terminal (shell) access only when doing a patch update or when requested to do so by the documentation or by Oracle support.

3.2 General Security Recommendations

Follow these general security recommendations for Oracle Audit Vault Server and Database Firewall (Oracle AVDF).

  • If you are using the Database Firewall to block unwanted traffic, then ensure that all data flowing from the database clients to the database and back passes through the Oracle Database Firewall. This includes both requests and responses.
  • Use the appropriate security measures for your site to control access to the computer that contains Oracle AVDF. Give access only to specific and trusted users, because someone with physical or virtual access to the console during installation can compromise the security of the installed system.
  • Ensure that passwords conform to best practice.
  • Separate the duties of administrators and auditors by assigning these roles to different people.
  • Assign the Audit Vault Server user the appropriate administrator, super administrator, auditor, and super auditor roles.
  • By default, the following accounts that are related to Oracle AVDF are locked: the Oracle OS user account, Oracle Grid accounts, any Oracle Database Vault accounts (for example, users who have been granted the DV_OWNER and DV_ACCTMGR roles). Ensure that these accounts remain locked.
  • Avoid sharing passwords between users and login sessions. Add new operating system users to distinguish access by different people.
  • When configuring system log forwarding, use suitable encryption to avoid giving actors with network access (such as network administrators) access to potentially sensitive data. See Configuring Remote Syslog Over TLS.
  • Database accounts AGENTUSR# and AVSRCUSR# belong to the AVS_NONINTERACTIVE profile prior to Oracle AVDF 20.9 and the AVS_AGENT_NONINTERACTIVE profile starting with Oracle AVDF 20.9. These accounts are created whenever a new agent or target is added. The passwords for these accounts are generated internally and starting in Oracle AVDF 20.9, the passwords are also rotated periodically. Oracle recommends that you do not modify the AGENTUSR# and AVSRCUSR# accounts including modifying password lifetime, failed login attempts, or the password. For more information, see Updating the Passwords of the AGENTUSR# and AVSRCUSR# Accounts.
  • Database account AVREPORTUSER belongs to the AVS_NONINTERACTIVE profile. Oracle recommends that you do not modify the AVREPORTUSER account including modifying password lifetime or failed login attempts.

3.3 External Network Dependencies

Ensure the security of your Oracle AVDF configuration by considering important external network dependencies.

When you add an external network service to Audit Vault Server or Database Firewall, you include these services to the trust model of your deployment.

For example, when you add a DNS server to an appliance, you trust the DNS server to provide the correct information about the host names that you look up. If someone compromises the DNS server, then they can control the network endpoints that are accessed by Audit Vault Server or Database Firewall using the host name.

There are analogous trust relationships in other services too, for example, NFS or NTP.

For this reason, add network services to Audit Vault Server or Database Firewall only when the following are adequately secure:

  • the service
  • the host server
  • the intermediate network

3.4 Considerations for Deploying Network-Based Solutions

Learn about what to consider when deploying network-based solutions.

3.4.1 Monitoring Encrypted Traffic with the Database Firewall

The Database Firewall supports monitoring Native Network Encrypted (NNE) traffic if it is configured between a database client and an Oracle Database.

Starting with Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20.7, the Database Firewall supports monitoring TLS-encrypted SQL traffic between a database client and an Oracle Database when the Database Firewall is deployed in proxy mode. The Database Firewall acts a TLS proxy terminating the session from the database client and creating a new TLS outbound session to the database server.

Starting with Oracle AVDF release 20.8, the Database Firewall supports monitoring TLS-encrypted SQL traffic between the database client and Oracle Real Application Clusters (Oracle RAC).

To monitor TLS traffic for non-Oracle databases, you can use TLS termination solutions to terminate TLS traffic just before it reaches the Database Firewall.

3.4.2 Managing Database Firewall Server Side SQL and Context Configurations

Learn how to manage Database Firewall SQL and context configurations.

Database Firewall policy enforcement relies on capturing and understanding SQL traffic between the database client and server. Because Database Firewall only analyzes network traffic between the application tier and the database server, the firewall cannot examine SQL that is directly sent from the database server. Some of the types of SQL statements that Database Firewall cannot examine are system provided and user defined SQL that you run from stored procedures and callouts. The firewall also cannot examine SQL that you run from background jobs, such as those that created by the DBMS_JOB or DBMS_SCHEDULER PL/SQL packages in Oracle databases, or SQL that is indirectly run from DDLs or other SQL statements. You can use the Oracle AVDF auditing features to capture these types of SQL statements.

Database Firewall builds its execution context entirely from the information that it captures from the network traffic. However, enforcement may depend on context information on the server. Any lack of context affects the resolution of identifiers that you use in database objects.

3.4.3 How Oracle AVDF Works with Various Database Access Paths

Learn how Oracle AVDF works with database access paths.

Oracle AVDF works with the following types of database access paths:

  • Non SQL protocol access: Database platforms support different network protocols beyond the database SQL based protocols. For example, Oracle Database supports HTTP, FTP, Advanced Queuing, Direct Path, and NFS access to the data in the database. The Database Firewall provides policy enforcement only for SQL based access to the database. The protocols that Database Firewall understands are Oracle TTC/Net and Tabular Data Stream (TDS) for Microsoft SQL Server, Sybase ASE, and IBM Distributed Relational Database Architecture (DRDA).

  • IPv6 Connections: Oracle AVDF does not support IPv6 deployments.

  • Non TCP based Connections: Database Firewall only supports TCP based network connections to database servers. It cannot monitor connections that are made to database servers using non TCP protocols such as Systems Network Architecture (SNA), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).

3.4.4 Database Firewall Configuration for Oracle Database Target Configured in Shared Server Mode

Learn about managing Database Firewall shared server configuration.

Shared server architectures enable databases to permit user processes to share server processes. A dispatcher process directs multiple incoming network session requests to a common queue, and then redirects these session requests to the next available process of the shared server. By default, Oracle Database creates one dispatcher service for the TCP protocol. In the init.ora file, this setting is controlled by the DISPATCHERS parameter, as follows:

dispatchers="(PROTOCOL=tcp)"

In the default configuration, a dynamic port listens to the incoming connection using the TCP protocol. With a shared server configuration, many user processes connect to a dispatcher on this dynamic port. If the Database Firewall is not configured to monitor the connections on this port, then the policy cannot be enforced on these connections. To facilitate the Database Firewall connection configuration, you should explicitly include the port number in the DISPATCHERS parameter. For example:

dispatchers="(PROTOCOL=tcp)(PORT=nnnn)"

Choose a value for nnnn, and configure the Database Firewall to protect that address, alongside the usual listener address.

See Also:

3.4.5 Additional Client and Listener Behavior Considerations

Learn about additional issues to be aware of with clients and shared listeners.

  • Client-side context: You can configure Oracle Database Firewall policies to use client-side context information such as client program name, client operating system username, and so on. After the client transmits this information to the database, Oracle Database Firewall captures it from the network. Oracle Database Firewall does not control or enforce the integrity of the client side or network. Consider the integrity of this information before using it to define security policies.

  • Multiple databases and services on a shared listener: Oracle Database Firewall supports policies based on Oracle Database service names. For non-Oracle databases, Oracle Database Firewall enforces policies that are based on the IP address and port number. In a configuration where a single listener endpoint (IP_address:port) is shared among multiple databases, Oracle Database Firewall cannot differentiate traffic that is directed to each individual database.

3.5 Security Considerations for Custom Collector Development

Learn about security considerations for Custom Collector Development.

3.5.1 Custom Collector Development

Learn about custom collector development.

Note the following if you develop custom collectors:

  • Prevent resource leaks. Ensure that JDBC resources are closed appropriately. These resources include the connections, result sets, and statements.
  • Prevent data loss. Ensure that your audit data is purged from the target system only after it has been successfully collected by the custom collector.
  • Avoid frequent queries to the target system.
  • Ensure that the custom collector does not consume a lot of system resources such as CPU and memory on the target host.
  • Avoid logging audit data because the audit records contain sensitive information.
  • Grant only the required privileges on the target system to users who have access to the Agent.
  • Ensure that only necessary files are added to custom collector .jar file.
  • Ensure that your custom collector code collects the audit data from your target system securely.

    Note:

    The collection framework ensures that audit data is transferred from the collector to Oracle Audit Vault Server securely.

3.6 About Setting Transport Layer Security Levels

Learn about setting Transport Layer Security (TLS) levels in Oracle AVDF.

This topic describes the different levels of connection encryption deployed on Oracle Audit Vault and Database Firewall appliances. Oracle AVDF uses TLS for inter component communication.

You can change the TLS levels and cipher suites for the following:

  • Connection between Audit Vault Server and the Agent or Host Monitor Agent

  • Connection between Host Monitor Agent and Database Firewall

  • Connection between Audit Vault Server and Database Firewall

  • Audit Vault Server console and the end user browsers

Note:

Connection Encryption Strength Used On Oracle AVDF Appliances

TLS Level TLS Version Description

Level-4

(Default on new installation)

 
TLSv1.2

This level is the strongest, restricting TLS to version 1.2 for inter communication between all the components in Oracle Audit Vault and Database Firewall.

Note:

It is recommended to use Level-4 for all services unless the supported service explicitly requires a lower level of TLS.

Level-3

 
TLSv1.2

This level supports everything that Level-4 does.

For Oracle AVDF releases 20.1 to 20.3:

  • If any Audit Vault Agent has to be deployed on IBM AIX, then set the TLS level to Level-3 or below (refer to row # 5 in the table below).
  • Level-3 uses TLS 1.2 or TLS 1.1 for Audit Vault Agent to Audit Vault Server communication. It is the same for Host Monitor Agent to Database Firewall communication.

Starting Oracle AVDF 20.4, Level-3 uses TLS 1.2 for Audit Vault Agent to Audit Vault Server communication. It is the same for Host Monitor Agent to Database Firewall communication.

Level-2

 
TLSv1.2
TLSv1.1

This level adds support for legacy and deprecated ciphers.

Note:

  • While upgrading to Oracle AVDF releases 20.1 to 20.3, the upgrade process does not automatically set to Level-4 to maintain connectivity while upgrading a multiple-appliance deployment. Upon completion of the upgrade, set to Level-4 unless interoperability with legacy systems is required.
  • While upgrading to Oracle AVDF releases 20.4 (or later), the upgrade process does not automatically set to Level-4 in all cases. After the upgrade process is complete (including Agents), it is strongly advisable to set to Level-4.

Level-1

(Custom)

 
TLSv1.2

This is a customizable cipher set that is configured with Level-4 strength by default.

How To Change TLS Levels and Other Tasks

Row No. Task Command Detailed Information

1

To check the existing TLS levels for Audit Vault Server and Database Firewall.

 
grep CIPHER_LEVEL /usr/local/dbfw/etc/dbfw.conf

Log in as support user and run this command. Use this command to check the actual configuration of the Audit Vault Server and Database Firewall.

2

To set the TLS level and to find more options.

 
/usr/local/dbfw/bin/priv/configure-networking --help

Log in as root user and run this command. By default, on a new installation the TLS level is set to Level-4.

On upgrade it is set to Level-2 by default. This is appropriate to most of the situations.

It is possible to change the level set. Use this command to find the options available.

3

To set TLS level for the Audit Vault Sever console.

 
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the TLS level for web browser connections to the AVS GUI. The levels can be set to 1, 2, 3, or 4.

4

To set TLS level for communication between Audit Vault Server and Database Firewall.

 
/usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the desired TLS level and restarts the internal services. The levels can be set to 1, 2, 3, or 4.

5

To set the TLS level for Audit Vault Agent to Audit Vault Server, and Host Monitor Agent to Database Firewall communication.

 
/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the TLS level for communication between the Audit Vault Agent to Audit Vault Server, and Host Monitor Agent to Database Firewall. The levels can be set to 1, 2, 3, or 4.

Note:

Perform the following steps to upgrade all Agents to the specified TLS levels after executing the configure-networking command:

1. Log in to the Audit Vault Server console as root user.

2. Change the directory by using the command:

cd /usr/local/dbfw/bin/priv

3. Execute the script using the command:

./send_agent_update_signal.sh

This command must not be executed more than once in a period of one hour.

6

To apply customized cipher set.

For Audit Vault Server console:

  • Edit: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    Run: 
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1

For Audit Vault Agent or Host Monitor Agent:

  • Edit: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

  • Run: 
    /usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level 1

For inter appliance communication:

  • Edit: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_services.xml

  • Run: 
    /usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level 1

By default, on a new installation the product is set to Level-4. On upgrade it is set to Level-2. This is appropriate to most of the situations. It is possible to customize. There are prompts and warning messages during the upgrade process which indicate that the cipher levels are not set to maximum security. The cipher levels are not automatically changed during upgrade.

Use this command to apply the custom defined level from the file created. These commands set the TLS level for web browser connections and restart the internal services and Audit Vault Server.

Note:

After running the command to apply customized cipher set, verify the error output in the system log file available at /var/log/messages to confirm that there are no errors in the file.

Log in as root user to run the command to edit the custom level configuration file. The customizable set of cipher suites is defined in this file. By default, on a new installation the product is set to Level-4. This file can be modified to further restrict the cipher suite and include ciphers available on the product.

7

To display the complete list of available cipher suites.

 
openssl ciphers -v

Log in as support user to run this command. Use this command to display the current set of available cipher suites.

8

To change TLS levels for inbound connection from the database client to the Database Firewall monitoring point.

See Modifying a Database Firewall Monitoring Point for complete information.

Starting with Oracle AVDF release 20.7, Database Firewall supports TLS encrypted SQL traffic. The TLS levels can be changed in the Advanced settings of the Database Firewall monitoring point using the Audit Vault Server console.

9

To change TLS levels for outbound connection from Database Firewall monitoring point to Oracle Database.

See Modifying a Database Firewall Monitoring Point for complete information.

Starting with Oracle AVDF release 20.7, Database Firewall supports TLS encrypted SQL traffic. The TLS levels can be changed in the Advanced settings of the Database Firewall monitoring point using the Audit Vault Server console.

When To Change TLS Levels

Oracle recommends leaving the internal TLS level at Level-4. Here is some more information on when to change the TLS levels:

Component Situation

Internal communication

Oracle recommends to set at Level–4 for increased security.

Audit Vault Server console (GUI)

To support old browsers, set the TLS level to match the browser.

Audit Vault Agent / Host Monitor Agent / Audit Vault Server

Oracle recommends to set at Level–4 for increased security.

Audit Vault Agent deployed with IBM AIX

On a fresh installation of Oracle AVDF releases 20.1 to 20.3, it is set to Level–4. Change the TLS level to Level-3 if any of the Audit Vault Agents are deployed on IBM AIX.

On a fresh installation of Oracle AVDF 20.4 and later, it is set to Level–4 and there is no change required.

Setting Custom Cipher Sets

Log in as root user to run this procedure for setting the custom cipher set. Do this by creating a custom file that defines the TLS levels and later applying the file.

  1. The customizable set of TLS levels are defined in the following files:

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

  2. The tls_configuration_custom_group.xml file can be modified as desired to include available ciphers on the product.
  3. Execute the following command to display the complete list of available ciphers:
    openssl ciphers –v
  4. Open the tls_configuration_custom_group.xml file and verify the format of the file. The format must be similar to the following:
    <?xml version="1.0" encoding='UTF-8' standalone='yes'?>
    <tls_configuration_groups xmlns='http://www.oracle.com/avdf'>
    <tls_configuration level="1">
    <ssl_protocols>
    <ssl_protocol>...</ssl_protocol>
    </ssl_protocols>
    <ssl_cipher_suite>
    <ssl_cipher>...</ssl_cipher>
    </ssl_cipher_suite>
    </tls_configuration>
    </tls_configuration_groups>
  5. In the customizable tls_configuration_custom_group.xml file, only the following tags can be added or removed as required:
    <ssl_protocol>...</ssl_protocol>
  6. Multiple tags can be applied in a sequence as follows:
    <ssl_cipher>...</ssl_cipher>
  7. The values must be any of the following Apache protocol values:
    1. TLSv1.2
    2. TLSv1.1
    3. TLSv1 (Deprecated)
  8. Execute the following command to apply the custom set.
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1

    See Also:

    Monitoring TLS Encrypted SQL Traffic

3.7 Certificates

Learn about different certificates in Oracle AVDF.

3.7.1 Platform Certificates

Learn all about Oracle AVDF platform certificates.

Oracle AVDF uses platform certificates for internal communication by various services.

Oracle AVDF release 20.6.0.0.0 and later provides the ability to renew platform certificates for Audit Vault Server and Database Firewall appliances before they expire. If the expiry period is less than 90 days, a warning message (ODF 10729) is displayed in the /var/log/messages file. See the action column against ODF 10729 in the section Database Firewall Messages for detailed procedure for renewing the certificates manually.

If the certificates are not renewed manually and if they are about to expire in less than 30 days, then the platform certificates are automatically renewed and all the relevant services are restarted.

3.7.2 Rotating Audit Vault Agent Certificates

Learn how to rotate Audit Vault Agent certificates.

Audit Vault Agent uses certificates for internal communication with various components and services. These certificates are valid for a specific duration according to the following table:

Table 3-1 Audit Vault Agent Certificate Validity

Audit Vault Server Release Audit Vault Agent Certificate Validity
Oracle AVDF 12.2 10 years
Oracle AVDF 20.1 and later 27 months
Follow these steps to rotate the Audit Vault Agent certificates.

Tip:

Starting with Oracle AVDF 20.9, if you have received a system alert that the certificate of your Audit Vault Agent is about to expire, you can skip to Step 4: Rotate the Audit Vault Agent Certificates.
3.7.2.1 About Audit Vault Agent Certificates

Learn about Audit Vault Agent certificates.

Audit Vault Agent certificates are used for communication between the Agent and Audit Vault Server. These Audit Vault Agent certificates have to be rotated or renewed for uninterrupted Oracle AVDF services.

Starting with Oracle AVDF release 20.7, the certificates can be renewed manually. For Oracle AVDF release 20.6 and prior, a patch needs to be applied before renewing the certificates.

After the Audit Vault Agent certificates are rotated or renewed, they are valid for a period of 27 months across all releases.

Note:

The certificate rotation or renewal is applicable to Audit Vault Agent and Host Monitor Agent.
3.7.2.2 Step 1: Download the Patch for Validating Audit Vault Agent Certificates (Oracle AVDF 20.1 to 20.9)

Download this patch to check the validity of the Audit Vault Agent certificates to determine when they will expire.

Applying patch 34412167 may restart the Audit Vault Agent. Before certificate rotation you should disable the autostart feature of Audit Vault Agent. See Autostarting the Agent on Windows Host for more information.
  1. Log in to My Oracle Support.
  2. Search for patch number 34412167.
  3. Download
    • For Oracle AVDF 20.1-20.7: p34412167_201000_Linux-x86-64.zip
    • For Oracle AVDF 20.8-20.9: p34412167_208000_Linux-x86-64.zip
  4. Extract the contents of the zip file.
  5. Copy show-agent-certificate.py from the extracted location to the /tmp directory on the Audit Vault Server.
3.7.2.3 Step 2: Check the Validity of the Audit Vault Agent Certificates (Oracle AVDF 20.1 to 20.9)

Check the validity of the Audit Vault Agent certificates to determine when they will expire.

  1. Connect to the Audit Vault Server through SSH as the root user.
  2. Switch to the oracle user:
    su - oracle
  3. Copy /tmp/show-agent-certificate.py to the $ORACLE_HOME/bin directory.
  4. Run the following command to check the validity of the Audit Vault Agent certificates:
    ./show-agent-certificate.py
  5. Note the expiration date.
3.7.2.4 Step 3: Patch the Audit Vault Agents to Enable Certificate Rotation (Oracle AVDF 20.1 to 20.6 Only)

If the results of Step 2 indicate that the agent certificates are already expired or will expire within the next three months, then you need to rotate the agent certificates. For Oracle AVDF release 20.1 to 20.6, you first need to patch the Audit Vault Agents to enable certificate rotation.

Note:

In a high availability environment, apply the patch on both the primary and standby Audit Vault Servers.

  1. Request a bundle patch for enhancement request (ER) 33869404.
  2. Follow the instructions in the README that comes with the patch to apply the patch on the Audit Vault Agents through the Audit Vault Server.

    Note:

    Apply this patch before rotating the Audit Vault Server certificate. See Rotating Audit Vault Server Certificates.
  3. Check the state of the Audit Vault Agents after the patching is complete.
    • If the certificates were already expired, then the agents will be in the STOPPED state.
    • If the certificates were not already expired, then the agents should be in the RUNNING state. If the agents are in the STOPPED state, then contact Oracle Support.
3.7.2.5 Step 4: Rotate the Audit Vault Agent Certificates

If the results of Step 2 indicate that the agent certificates are already expired or will expire within the next 30 days, then you need to rotate the agent certificates.

If certificates have expired, you will have to manually rotate certificates through the steps for Oracle AVDF 20.10.

Ensure that all components of your AVDF system, Audit Vault Server(s), Audit Vault Agent(s), and Database Firewall(s), are up prior to performing certificate rotation. If certificates are rotated while a component is down, the component may not work the next time it is brought back up.

  1. Log in to the Audit Vault Server Console as a super administrator.

  2. Click the Settings tab.
  3. In the Security section, click the Certificates tab.
  4. Click the Rotate Certificates tab.
  5. Click either Rotate CA Certificates to rotate all certificate authorities (CA) and service certificates or Rotate Service Certificates to only rotate the service certificates on the following:
    • The primary Audit Vault Server, including the UI certificate if it is not externally signed.

      The SSO certificate will not be rotated as this must be done manually. See Rotating the Audit Vault Server SSO Certificate for more information.

    • The secondary Audit Vault Server, if set up in a high availability environment
    • Any registered Audit Vault Agents
    • Any registered Database Firewalls

      Note:

      If the certificate authority is rotated, it will invalidate the certificates that have been signed by the Database Firewall certificate authority. Therefore, TLS proxy certificates should be signed externally by an appropriate certificate authority. See Creating TLS Proxy Certificates for Database Firewall for more information.
  6. Click OK to confirm certificate rotation.

    While the certificates are being rotated the UI may be unavailable for some time.

Note:

In a high availability environment, follow these steps for the primary Audit Vault Server only.

  1. Log in to the Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Change the directory:
    cd /opt/avdf/lib/ruby/avdf
  3. Run the following command to rotate the Audit Vault Agent certificates:
    ruby update_agent_cert_task.rb
  4. If the certificate was already expired and you're using agentless collection,

    1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Run the below command to redeploy Agentless Collection Service
      /usr/local/dbfw/bin/deploy_default_agent.py

Note:

In a high availability environment, follow these steps for the primary Audit Vault Server only.

  1. Connect to the Audit Vault Server through SSH as the root user.
  2. Change the directory: 
    cd /opt/avdf/lib/ruby/avdf
  3. Run the following command to rotate the Audit Vault Agent certificates: 
    ruby update_agent_cert_task.rb
  4. If the certificates were already expired:

    1. Log in to the Audit Vault Server Console as an administrator.

    2. Click the Agents tab.
    3. Select the check box for all stopped agents, and then click Deactivate.
    4. Select the check box of all agent that were deactivated, and then click Activate.
    5. Copy or make a note of the agent activation key for all agents.
    6. Click Downloads in the left navigation menu.
    7. Download the agent.jar
    8. Transfer the agent.jar file to all the agent machines.
    9. Start all the Audit Vault Agents by running the bellow commands: 
      1. agentctl start -k
      2. Paste or enter the agent activation key in the following format:

        <Agent Name>::XXXX-XXXX-XXXX-XXXX-XXXX

        The activation key is not displayed as you type it.

    If you're using agentless collection in Oracle AVDF 20.9, perform these steps if the certificate was already expired

    1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Run the below command to redeploy Agentless Collection Service
      /usr/local/dbfw/bin/deploy_default_agent.py
  5. If the certificates were not already expired:
    1. Validate the Audit Vault Agent certificate after the rotation. See Step 2: Check the Validity of the Audit Vault Agent Certificates (Oracle AVDF 20.1 to 20.9).

      The Audit Vault Agent takes at most 12 hours to update the new certificates. The time depends on the number of agents that are registered on the Audit Vault Server.

    2. After 12 hours, verify that the Audit Vault Agents are in the RUNNING state. If they are in the STOPPED state, then contact Oracle Support.
  6. If you disabled the autostart feature of Audit Vault Agent prior to applying patch 34412167, re-enable it. See Autostarting the Agent on Windows Host for more information.

3.7.3 Rotating Audit Vault Server Certificates

Learn how to rotate Audit Vault Server certificates.

Audit Vault Server uses certificates for internal communication with various components and services. Oracle AVDF enables you to rotate Audit Vault Server certificates before they expire.

If certificates have expired, you will have to manually rotate certificates through the steps for Oracle AVDF 20.10.

Ensure that all components of your AVDF system, Audit Vault Server(s), Audit Vault Agent(s), and Database Firewall(s), are up prior to performing certificate rotation. If certificates are rotated while a component is down, the component may not work the next time it is brought back up.

  1. Log in to the Audit Vault Server Console as a super administrator.

  2. Click the Settings tab.
  3. In the Security section, click the Certificates tab.
  4. Click the Rotate Certificates tab.
  5. Click either Rotate CA Certificates to rotate all certificate authorities (CA) and service certificates or Rotate Service Certificates to only rotate the service certificates on the following:
    • The primary Audit Vault Server, including the UI certificate if it is not externally signed.

      The SSO certificate will not be rotated as this must be done manually. See Rotating the Audit Vault Server SSO Certificate for more information.

    • The secondary Audit Vault Server, if set up in a high availability environment
    • Any registered Audit Vault Agents
    • Any registered Database Firewalls

      Note:

      If the certificate authority is rotated, it will invalidate the certificates that have been signed by the Database Firewall certificate authority. Therefore, TLS proxy certificates should be signed externally by an appropriate certificate authority. See Creating TLS Proxy Certificates for Database Firewall for more information.
  6. Click OK to confirm certificate rotation.

    While the certificates are being rotated the UI may be unavailable for some time.

  1. Generate new certificate authority (CA) certificates on the Audit Vault Server by the following command as the root user. This process updates the central, self-signed CA certificate on the Audit Vault Server. 
    /usr/local/bin/gensslcert destroy-certs create-ca
  2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  3. Update and regenerate the CA certificate bundles and services.

    1. Run the following command as the root user on the primary Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller
  4. Run the following command as the root user on the primary server: 
    systemctl start monitor
  5. Copy and transfer the new CA certificates from the Audit Vault Server to each of the linked Database Firewall instances:
    Run as the root user on the primary server:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Run as the root user on the Database Firewall:
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  6. Update the Database Firewall and Audit Vault Server controllers:

    Run as the root user on the Database Firewall: 

    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  7. Restart the Database Firewall appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart stund
  8. Verify that the local and peer certificates are valid.

    Verify the following local certificates:

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    Verify the following peer certificates:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity: 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. Generate new certificate authority (CA) certificates on the primary Audit Vault Server by the following command as the root user. This process updates the central, self-signed CA certificate on the Audit Vault Server. 
    /usr/local/bin/gensslcert destroy-certs create-ca
  2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  3. Transfer the CA certificates from the primary Audit Vault Server to the standby Audit Vault Server:
    Run as the root user on the primary server: 
    scp /usr/local/dbfw/etc/ca.crt support@<standby-ip>:/tmp/ha_partner.crt
    Run as the root user on the standby server: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
  4. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  5. Regenerate the CA certificates and all certificates on the standby Audit Vault Server instance.

    Run as the root user on the standby server: 

    /usr/local/bin/gensslcert destroy-certs create-ca
  6. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  7. Transfer the standby CA certificates to the primary instance:
    Run as the root user on the primary server: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
    Run as the root user on the standby server: 
    scp /usr/local/dbfw/etc/ca.crt support@<primary-ip>:/tmp/ha_partner.crt
  8. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  9. Update and regenerate the CA certificate bundles and services. Perform these steps on the primary and standby Audit Vault Server instances one at a time.

    1. Run the following command as the root user on the primary Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller

    3. Run the following command as the root user on the standby Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    4. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller
  10. Restart the observer on the primary Audit Vault Server server:
    Run as the root user on the primary server: 
    systemctl stop monitor

    Switch to the oracle user.

    su - oracle
    Run as the oracle user on the primary server:
    /usr/local/dbfw/bin/observerctl --stop
    /usr/local/dbfw/bin/observerctl --start
  11. Wait for two minutes for the observer process to come up.

    To check the observer status:

    1. Log in to the Audit Vault Server through SSH as the support user.

      Note:

      If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, connect through SSH as the OPC user. 
      ssh support@<audit_vault_server_ip_address>

    2. Switch to the root user.

      su - root

      Note:

      If you're using the OCI marketplace image, use the sudo su - command.

    3. Switch to the oracle user.

      su - oracle

    4. Run the following command:

      /usr/local/dbfw/bin/setup_ha.rb –status

      This displays all statuses, including the Data Guard observer status. It displays Data guard observer = yes when the observer is running.

  12. Run the following command as the root user on the primary server: 
    systemctl start monitor
  13. Copy and transfer the new CA certificates from the primary and standby instances to each of the linked Database Firewall instances:
    Run as the root user on the primary server:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Run as the root user on the standby server:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/standby.ca
    Run as the root user on the Database Firewall:
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  14. Update the Database Firewall and Audit Vault Server controllers:

    Run as the root user on the Database Firewall: 

    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  15. Restart the Database Firewall appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart stund
  16. Verify that the local and peer certificates are valid.

    Verify the following local certificates:

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    Verify the following peer certificates:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity: 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. Log in to My Oracle Support.
  2. Search for patch number 34378212.
  3. Download p34378212_191000_Linux-x86-64.zip.
  4. Extract the contents of the zip file.
  5. Copy gensslcert.avs.tar.gz from the extracted location to the /tmp directory on the Audit Vault Server.
  6. Complete the installation on the Audit Vault Server:

    1. Log in to the Audit Vault Server through SSH as the support user.

      Note:

      If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, connect through SSH as the OPC user. 
      ssh support@<audit_vault_server_ip_address>

    2. Switch to the root user.

      su - root

      Note:

      If you're using the OCI marketplace image, use the sudo su - command.

    3. Create a new directory:

      mkdir /root/gensslcert

    4. Copy gensslcert.avs.tar.gz to the new directory: 

      cp /tmp/gensslcert.avs.tar.gz /root/gensslcert

    5. Change to the new directory:

      cd /root/gensslcert

    6. Extract the files:

      tar xvfz gensslcert.avs.tar.gz
  7. Generate new certificate authority (CA) certificates on the Audit Vault Server by running the following command as the root user. This process updates the central, self-signed CA certificate on the Audit Vault Server.
    /root/gensslcert/gensslcert destroy-certs create-ca
  8. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  9. Update and regenerate the CA certificate bundles and services.

    1. Run the following command as the root user on the Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller
  10. Run the following command as the root user on the primary server: 
    systemctl start monitor
  11. Copy and transfer the new CA certificates from the Audit Vault Server to each of the linked Database Firewall instances:
    Run as the root user on the primary server: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Run as the root user on the Database Firewall: 
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  12. Update the Database Firewall and Audit Vault Server controllers:
    Run as the root user on the Database Firewall: 
    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  13. Restart the Database Firewall appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart stund
  14. Verify that the local and peer certificates are valid.

    Verify the following local certificates:

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    Verify the following peer certificates:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity: 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. Log in to My Oracle Support.
  2. Search for patch number 34378212.
  3. Download p34378212_191000_Linux-x86-64.zip.
  4. Extract the contents of the zip file.
  5. Copy gensslcert.avs.tar.gz from the extracted location to the /tmp directory on the Audit Vault Server.
  6. Complete the installation on the Audit Vault Server:

    1. Log in to the Audit Vault Server through SSH as the support user.

      Note:

      If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, connect through SSH as the OPC user. 
      ssh support@<audit_vault_server_ip_address>

    2. Switch to the root user.

      su - root

      Note:

      If you're using the OCI marketplace image, use the sudo su - command.

    3. Create a new directory:

      mkdir /root/gensslcert

    4. Copy gensslcert.avs.tar.gz to the new directory: 

      cp /tmp/gensslcert.avs.tar.gz /root/gensslcert

    5. Change to the new directory:

      cd /root/gensslcert

    6. Extract the files:

      tar xvfz gensslcert.avs.tar.gz
  7. Generate new certificate authority (CA) certificates on the primary Audit Vault Server by running the following command as the root user. This process updates the central, self-signed CA certificate on the Audit Vault Server.
    /root/gensslcert/gensslcert destroy-certs create-ca
  8. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  9. Transfer the CA certificates from the primary Audit Vault Server to the standby Audit Vault Server:
    Run as the root user on the primary server: 
    scp /usr/local/dbfw/etc/ca.crt support@<standby-ip>:/tmp/ha_partner.crt
    Run as the root user on the standby server: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
  10. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  11. Regenerate the CA certificates and all certificates on the standby Audit Vault Server instance by running the following command as the root user.
    /root/gensslcert/gensslcert destroy-certs create-ca
  12. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  13. Transfer the standby CA certificates to the primary instance:
    Run as the root user on the primary server: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
    Run as the root user on the standby server: 
    scp /usr/local/dbfw/etc/ca.crt support@<primary-ip>:/tmp/ha_partner.crt
  14. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart controller
  15. Update and regenerate the CA certificate bundles and services. Perform these steps on the primary and standby Audit Vault Server instances one at a time.

    1. Run the following command as the root user on the primary Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. Restart the primary Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller

    3. Run the following command as the root user on the standby Audit Vault Server appliance: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    4. Restart the standby Audit Vault Server appliance. As the root user run the following commands:
      systemctl reload httpd
      systemctl restart controller
  16. Restart the observer on the primary Audit Vault Server server:
    Run as the root user on the primary server: 
    systemctl stop monitor

    Switch to the oracle user.

    su - oracle
    Run as the oracle user on the primary server: 
    /usr/local/dbfw/bin/observerctl --stop
    /usr/local/dbfw/bin/observerctl --start
  17. Wait for two minutes for the observer process to come up.

    To check the observer status:

    1. Log in to the Audit Vault Server through SSH as the support user.

      Note:

      If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, connect through SSH as the OPC user. 
      ssh support@<audit_vault_server_ip_address>

    2. Switch to the root user.

      su - root

      Note:

      If you're using the OCI marketplace image, use the sudo su - command.

    3. Switch to the oracle user.

      su - oracle

    4. Run the following command:

      /usr/local/dbfw/bin/setup_ha.rb –status

      This displays all statuses, including the Data Guard observer status. It displays Data guard observer = yes when the observer is running.

  18. Run the following command as the root user on the primary server: 
    systemctl start monitor
  19. Copy and transfer the new CA certificates from the primary and standby instances to each of the linked Database Firewall instances:
    Run as the root user on the primary server: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Run as the root user on the standby server: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/standby.ca
    Run as the root user on the Database Firewall: 
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  20. Update the Database Firewall and Audit Vault Server controllers:
    Run as the root user on the Database Firewall: 
    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  21. Restart the Database Firewall appliance. As the root user run the following commands:
    systemctl reload httpd
    systemctl restart stund
  22. Verify that the local and peer certificates are valid.

    Verify the following local certificates:

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    Verify the following peer certificates:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity: 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt

3.7.4 Rotating Database Firewall Certificates

Learn how to rotate Database Firewall certificates.

Database Firewall uses certificates for internal communication with various components and services. Oracle AVDF enables you to rotate Database Firewall certificates before they expire.

Note:

Rotate certificates for each Database Firewall instance including those paired for high availability.

If certificates have expired, you will have to manually rotate certificates through the steps for Oracle AVDF 20.10.

Ensure that all components of your AVDF system, Audit Vault Server(s), Audit Vault Agent(s), and Database Firewall(s), are up prior to performing certificate rotation. If certificates are rotated while a component is down, the component may not work the next time it is brought back up.

  1. Log in to the Audit Vault Server Console as a super administrator.

  2. Click the Settings tab.
  3. In the Security section, click the Certificates tab.
  4. Click the Rotate Certificates tab.
  5. Click either Rotate CA Certificates to rotate all certificate authorities (CA) and service certificates or Rotate Service Certificates to only rotate the service certificates on the following:
    • The primary Audit Vault Server, including the UI certificate if it is not externally signed.

      The SSO certificate will not be rotated as this must be done manually. See Rotating the Audit Vault Server SSO Certificate for more information.

    • The secondary Audit Vault Server, if set up in a high availability environment
    • Any registered Audit Vault Agents
    • Any registered Database Firewalls

      Note:

      If the certificate authority is rotated, it will invalidate the certificates that have been signed by the Database Firewall certificate authority. Therefore, TLS proxy certificates should be signed externally by an appropriate certificate authority. See Creating TLS Proxy Certificates for Database Firewall for more information.
  6. Click OK to confirm certificate rotation.

    While the certificates are being rotated the UI may be unavailable for some time.

  1. Generate the new certificate authority (CA) certificates on the Database Firewall appliance. First regenerate the local CA certificates on the Database Firewall appliance by running one of the following commands.
    dbfw(root)$ /usr/local/bin/gensslcert destroy-certs create-ca
  2. Run the following commands to restart the Database Firewall services: 
    dbfw(root) $ systemctl reload httpd
    dbfw(root) $ systemctl restart stund
  3. Update the Database Firewall certificate on the Audit Vault Server and regain control of the Database Firewall. See Fetching an Updated Certificate from Database Firewall.
  4. Verify that the following local certificates are valid:
    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity. 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  5. Verify that the following peer certificates are valid:
    • /usr/local/dbfw/etc/controller.crt
    • /usr/local/dbfw/etc/controller_second.crt
    • /usr/local/dbfw/etc/fw_ca.crt
  1. Log in to My Oracle Support.
  2. Search for patch number 34378217.
  3. Download p34378217_191000_Linux-x86-64.zip.
  4. Extract the contents of the zip file.
  5. Copy gensslcert.dbfw.tar.gz from the extracted location to the /tmp directory on the Database Firewall server.
  6. Follow these steps to complete the installation on the Database Firewall Server:

    1. Connect to the Database Firewall appliance through SSH as the support user.

    2. Switch to the root user: 

      su - root

    3. Create a new directory:

      mkdir /root/gensslcert

    4. Copy gensslcert.dbfw.tar.gz to the new directory: 

      cp /tmp/gensslcert.dbfw.tar.gz /root/gensslcert

    5. Change to the new directory:

      cd /root/gensslcert

    6. Run the following command:

      tar xvfz gensslcert.dbfw.tar.gz
  7. Generate the new certificate authority (CA) certificates on the Database Firewall appliance. First regenerate the local CA certificates on the Database Firewall appliance by running one of the following commands.
    dbfw(root)$ /root/gensslcert/gensslcert destroy-certs create-ca
  8. Run the following commands to restart the Database Firewall services: 
    dbfw(root) $ systemctl reload httpd
    dbfw(root) $ systemctl restart stund
  9. Update the Database Firewall certificate on the Audit Vault Server and regain control of the Database Firewall. See Fetching an Updated Certificate from Database Firewall.
  10. Verify that the following local certificates are valid:
    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt

    Use the config-diagnostics, sappdiag, or openssl x509 command to verify the certificate validity. 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  11. Verify that the following peer certificates are valid:
    • /usr/local/dbfw/etc/controller.crt
    • /usr/local/dbfw/etc/controller_second.crt
    • /usr/local/dbfw/etc/fw_ca.crt

3.7.5 Rotating the Audit Vault Server SSO Certificate

Starting in Oracle AVDF 20.11, you can configure single sign-on (SSO) for Audit Vault Server console users. Learn how to rotate the SSO key and certificate.

Rotation of the SSO certificate must be done manually as it does not rotate through the functionality available in the Rotate Certificates tab of the Audit Vault Server.

  1. Log in to the Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Go to the /usr/local/dbfw/etc directory:
    cd /usr/local/dbfw/etc
  3. Create a backup directory and move the current Apex SAML key and certificate files there.
    mkdir apexsaml_backup
mv apexsaml.key ./apexsaml_backup
mv apexsaml.crt ./apexsaml_backup
  4. Generate the Apex SAML key and certificate:
    /usr/local/dbfw/etc/privileged-migrations/gen_saml_apex_cert.sh
  5. Register them with Audit Vault Server:
    /usr/local/dbfw/etc/privileged-migrations/register_apex_key_cert.py
  6. Test the SSO configuration by logging in to the Audit Vault Server console.

    See Logging In to Oracle AVDF Appliances Through SSO for more information.

  7. Remove the backup directory for Apex SAML key and certificate if the SSO connection testing is working fine:
    rm -r /usr/local/dbfw/etc/apexsmal_backup
  8. If your identity provider requires the Audit Vault Server SSO certificate, update the identity provider configuration with the new SSO certificate.
  9. If configured in high availability, copy the /usr/local/dbfw/etc/apexsaml.key and /usr/local/dbfw/etc/apexsaml.crt to the standby Audit Vault Server.

Related Topics

3.7.6 Creating TLS Proxy Certificates for Database Firewall

Learn how to create and upload TLS proxy certificates for Database Firewall.

Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20.8 (and later) supports managing TLS proxy certificates for Database Firewall from the Audit Vault Server console.

Database Firewall uses certificates for inbound (database client to Database Firewall) and outbound (Database Firewall to target database) TLS connections. You can create and manage certificates for both inbound and outbound TLS connections through the Audit Vault Server console.

Note:

  • This functionality is available to Oracle Database versions that are supported by Oracle AVDF. It is not applicable to Oracle Real Application Clusters (Oracle RAC) instances in Oracle AVDF release 20.7. It is supported starting with Oracle AVDF release 20.8.
  • This functionality is applicable to Database Firewall instances that are deployed in Monitoring / Blocking (Proxy) mode only.
  • When using Database Firewall as a TLS proxy, password-based user authorization with the database is supported. Certificate-based authorization and third-party user authorization (RADIUS, Kerberos, LDAP, and so on) with the database are not supported.

The following types of certificate signing methods are supported:

  • Certificates that are signed by the Database Firewall certificate authority (CA)

    You can use out-of-the-box certificates that are signed by the Database Firewall CA for inbound and outbound TLS connections. Oracle strongly recommends that you use third-party, externally signed certificates for production deployments.

    You can choose this option when configuring monitoring points for a target database.

  • Certificates that are signed by an external CA

    To use a certificate that is signed by an external CA, create a certificate signing request (CSR) with the relevant information, download it, get the certificate signed, and upload it using the Audit Vault Server console.

    After you upload the certificate, you can use it when configuring monitoring points for a target database.

Follow these steps to generate a CSR, download the CSR, and upload the duly signed certificate to the Database Firewall:

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. Click the Security tab in the left navigation menu.
    Only super administrators can see the subtabs and settings on the main page of the Security tab.
  4. Click the Certificate subtab on the main page.
  5. Click the Database Firewall subtab.
  6. Click the Generate CSR button.

    The Generate Certificate Signing Request (CSR) dialog box appears.

  7. Select the specific Database Firewall instance from the drop-down list.
  8. Enter a common name.
  9. Enter the organization name for the certificate.
  10. Select the country or region.
  11. (Optional) Complete the following fields:
    • Organizational Unit
    • State/Province
    • City
    • Email
  12. Click Create to submit the CSR.
  13. Click Download CSR and save the certificate to the local machine.
  14. Get the certificate duly signed by a CA.
  15. After the CA approves the certificate, click Upload Certificate.

    The Upload Certificate dialog box appears.

  16. Select the file from the local machine.
  17. Click Upload.
  18. Use the newly uploaded certificate when configuring monitoring points for a target database.
    See Modifying a Database Firewall Monitoring Point for complete instructions.
3.7.6.1 Viewing Certificate Details

In the Audit Vault Server console, you can view the details for each TLS proxy certificate, including the status, start and end dates, expiry time, common name, and so on.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. Click the Security tab in the left navigation menu.
  4. Click the Certificate subtab on the main page.
  5. Click the Database Firewall subtab.
3.7.6.2 Rotating Certificates

You can also rotate the TLS proxy certificates for Database Firewall.

For Database Firewall CA signed certificates, rotating creates new certificates and assigns them to the same monitoring points.
For externally signed CA certificates, rotating creates a new CSR using the previously configured values. You need to download the certificate and follow the same procedure that you followed to create it, get it signed, and upload it.