Avamar: Session Security

What is Session Security?

Session Security: Product Security Guide

Avamar clients can use session security to secure all communications between the Avamar server and the Avamar client software. The Avamar server provides authentication to the Avamar client and the Avamar client provides authentication to the Avamar server.

Session security features include security improvements for communications between Avamar system processes.
The Avamar secures all communications between Avamar system processes by using session tickets. A valid session ticket is required before an Avamar process accepts a transmission from another Avamar process.

The session tickets have the following general characteristics:

• The session ticket is encrypted and signed to protect against modification
• The session ticket is valid for a short time
• Each session ticket contains a unique signature and is assigned to only one Avamar process
• The integrity of a session ticket is protected by encryption
• Each Avamar system node separately verifies the session ticket signature
• When required, a session can be extended beyond the life of the session ticket

Avamar acts as a private certification authority and generates a unique server certificate for the Avamar system.

The Avamar system installs the public key for the server certificate on every Avamar client that is registered with the Avamar server. Avamar clients use the public key to authenticate transmissions from the Avamar system.

For clients that are currently registered, the public key for the server certificate and other required certificate files are propagated to the client within an hour of the installation.

The Avamar system also automatically shares the Avamar server certificate with the Avamar storage nodes. Sharing the certificate allows the utility node and the storage nodes to provide the same certificate for authentication.

A client certificate is generated when the Avamar server registers an Avamar client.

After generating a client certificate, the Avamar system uses an encrypted connection with the Avamar client to install the certificate on the client. The Avamar system also stores the public key for the client certificate. The public key is used to authenticate the client in all subsequent communications.

How does Session Security work?

Session Security is enabled on the Avamar server. When enabled, clients, proxies, and Data Domain systems go through a special certificate registration process with Avamar.

On a windows or linux client and proxy, at registration time it sees that the Avamar server has Session Security enabled. The Avamar sends its internal root CA to the client (chain.pem) so that the client can store and trust it. The client generates a certificate signing request (CSR). The CSR (avclient.csr) will be sent from the client to the Avamar server's MCS process which will sign the CSR and give back a certificate keypair to the client (key.pem & cert.pem).

On a Data Domain, when attaching the Data Domain to Avamar or when the SSL communication is refreshed, Avamar will see that the Data Domain does not have a signed certificate from itself or another validated Avamar (imported-host ddboost). Avamar will use the Data Domain ssh private key to log in to the Data Domain to run "ssh" commands over the Data Domin shell (ddsh). Avamar will pull the Data Domain certificate signing request (CSR) over SCP, and sign the CSR with the Avamar internal root CA. Once the Data Domain has the signed certificate from Avamar (imported-host ddboost), Avamar will import the root CA which signed the certificate (chain.pem as imported-ca ddboost/login-auth).

Now that a client/proxy is registered and has the client-side certificates required to authenticate with the Avamar's MCS, a backup is attempted. The Avamar sends a workorder to the client or proxy's Avagent listener, which picks up the workorder. The client or proxy then validates and verifies the Avamar server's certificate chain by using the Avamar root CA which Avamar had imported to the client at registration time. Likewise, Avamar authenticates the client or proxy. No data has been passed at this point.

After authentication is successful, the workorder starts and the status of the workorder changes from 'Waiting-Client' to 'Running'.

Now, clients and proxies eventually move data to Avamar and Data Domain by using the avtar binary installed on them. The avtar binary will pass some flags that control the details of how the data is moved and what data is moved.

When avtar on a client or proxy goes to connect to Avamar's GSAN it must know if verifypeer is enabled. The verifypeer setting is a GSAN server setting as part of the Session Security configuration which controls GSAN's SSL socket on port 29000 by telling it whether or not to require client certificates for every incoming connection. Luckily, the TLS 1.2 protocol is implemented which automatically handles how a client or proxy shall present their client certificates to gsan during the TLS handshake.

The following is a demonstration of the TLS mutual/two-way handshake when verifypeer is enabled.
From the client or proxy point-of-view, an arrow pointing to the right is a connection to the Avamar server. An arrow pointing to the left is a connection coming from the Avamar server to the client.

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, CertificateRequest
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Certificate
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, CertificateVerify
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Finished

When verifypeer is disabled, the client is not required to send a client certificate to GSAN.

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 Handshake, Finished

The important part is that the client or proxy got the necessary client-side certificates to be able to perform a mutual TLS handshake if required by GSAN.

This means, if the Avamar internal root CA changes, the client, proxy, or Data Domain must get the new root CA to sign certificates for them.

After the client or proxy connects to GSAN successfully, it attempts to connect to the Data Domain.

The following log shows a proxy connecting to Data Domain with avtar. The verifypeer setting is disabled, but Session Security is enabled (Authenticated-Single mode).

2024-02-22 17:37:32 avtar Info <40058>: - Client connecting to the Avamar Server using authentication, client connecting to the Data Domain system using two-way authentication
2024-02-22 17:37:33 avtar Info <44068>: - Data Domain Engine Set FIPS OFF
2024-02-22 17:37:33 avtar Info <16684>: - Data Domain Engine (7.11.0.0 build 1033042)
2024-02-22 17:37:33 avtar Info <40174>: Multi-stream restore via cloning is enabled.
2024-02-22 17:37:33 avtar Info <10632>: Using Client-ID='6bf19b025be80a12da2e7b932da60079709906ae'
2024-02-22 17:37:33 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = lab.dd.com
2024-02-22 17:37:33 avtar Info <10539>: Connecting to Data Domain Server "lab.dd.com"(1)  (LSU: avamar-1704339590) with auth token
2024-02-22 17:37:33 avtar Info <10540>: - Resolved Data Domain Server name "lab.dd.com" to the IP address "10.x.x.x"
2024-02-22 17:37:33 avtar Info <41236>: - Connecting to Data Domain Server name "lab.dd.com" with token:e2602cc64ce8c4782ca877cabe355191042d0fb4
2024-02-22 17:37:33 avtar Info <0000>: - Connecting to:
DataDomain:           lab.dd.com
encryption strength:  2
auth_mode:            2
client_cert           /usr/local/avamarclient/etc/cert.pem
client_key:           /usr/local/avamarclient/etc/key.pem
server_cert:          /tmp/.tmp_avamar/MOD-1708623043157#1_65d7865c_68ce32dc.pem
chain_cert:           /usr/local/avamarclient/etc/chain.pem

Since verifypeer is an Avamar GSAN server setting, it does not impact how avtar connects directly to Data Domain if Session Security is enabled. This means that a mutual TLS handshake occurs between the client or proxy and the Data Domain.

The client or proxy can validate the Data Domain certificate chain because it shares the same Avamar internal root CA which was imported by Avamar at client registration time (or DD edit or attachment time).

Proxy
------
Avamar internal root CA
/usr/local/avamarclient/etc/chain.pem


Data Domain
--------------
Avamar internal root CA
run command to view certificate list on DD: adminaccess certificate show
imported-ca ddboost


/usr/local/avamarclient/etc/chain.pem == imported-ca ddboost

After certificate validation the handshake completes, and backup data is moved from client to Data Domain and Avamar on the network.

Managing Session Security Settings

The following two articles are used to manage the Session Security settings either from the command-line or the Avinstaller web service.

Avamar: Manage Session Security Settings from CLI
Avamar: Manage Session Security Settings with Avinstaller Installation Package (AVP)

There are four possible supported configurations:

1. Disabled
2. Mixed-Single
3. Authenticated-Single
4. Authenticated-Dual

Disabled

Settings:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="false"
"secure_agent_feature_on"                               ="false"
"session_ticket_feature_on"                             ="false"
"secure_agents_mode"                                    ="unsecure_only"
"secure_st_mode"                                        ="unsecure_only"
"secure_dd_feature_on"                                  ="false"
"verifypeer"                                            ="no"

When Session Security is disabled, clients only connect to Avamar's Avagent service on port 28001, and the clients listen on Avagent port 28002 for requests from Avamar.

A proxy listens on 28009.

Port 28001 is a plain TCP socket and does not perform TLS handshakes.

The client connects to the Avamar GSAN on port 29000 and performs a one-way TLS handshake. This means that even when Session Security is disabled, when backup data is transferred between the client and Avamar it is encrypted in flight still.

Certificates for authentication with the Avamar software are not exchanged between Avamar, proxies, clients, and Data Domain.

Mixed-Single

Settings:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="mixed"
"secure_st_mode"                                        ="mixed"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

Mixed-Single mode was used more when Session Security was first introduced in Avamar 7.3, specifically allowing those clients whose version was not 7.3 or above to register and back up to Avamar. At the time of writing this article, Avamar 19.10 is the latest version and Mixed-Single will essentially be the same as the next mode to discuss; Authenticated-Single.

Authenticated-Single

Settings:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

In this mode, Session Security is enabled and certificates are passed between Avamar, clients, proxies, and Data Domain for authentication prior to a backup.

Clients now listen on port 30002 for Avagent workorder requests from Avamar, and the proxies listen on port 30009. The Avamar listens on ports 30001 and 30003 for connection requests from clients and proxies. These are SSL sockets which perform TLS handshakes.

Authenticated-Single mode forces all clients to register using Session Security methods unlike Mixed-Single mode.

This mode sets verifypeer on Avamar's GSAN to disabled, meaning GSAN will not require client certificates from an inbound avtar connection.

Authenticated-Dual

Settings:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="yes"

Authenticated-Dual is the same as Authenticated-Single except it enables verifypeer setting on Avamar's GSAN service.

Authenticated-Dual is considered the strongest setting to apply to an Avamar server and is the default selection during Avamar deployments.

Overview: Avamar internal self-signed root CA

The Avamar internal root CA is an internally trusted certificate authority to Avamar and the clients, proxies, and Data Domains that Avamar imports to them.

Avamar is the internal CA for itself because it issues certificates for certificate signing requests (CSRs).

When Avamar uses its root CA to sign certificates for GSAN, they are stored in the following location:

/home/admin/chain.pem
/home/admin/cert.pem
/home/admin/key.pem

/usr/local/avamar/etc/chain.pem
/usr/local/avamar/etc/cert.pem
/usr/local/avamar/etc/key.pem

If a security scanner scans port 29000 on Avamar, it will report self-signed certificates on that port which processes backups to GSAN.

In some environments, this may not be acceptable, and the recommendation is to see the following KB article for more information about replacing the Avamar internal root CA with a user supplied internal root CA.

Avamar: Install or Replace Avamar Certificate Authority (CA) with User Supplied Certificate Authority (CA) 

The process details how to use the importcert.sh script to install a user-supplied certificate authority internal to their company. The user-supplied certificate authority is likely managed by the security team, as no public certificate authority will give away the private key for their CA as it is the reason they make money by signing certificates for others and maintaining a chain of trust.

An example of an internal CA would be Microsoft Active Directory Certificate Services.
What is Active Directory Certificate Services? | Microsoft Learn

An example of a public CA would be DigiCert.

Replacing the Avamar internal root CA works by replacing the root keypair in the Avamar keystore with the user supplied CA keypair. Then GSAN generates a CSR and private key, gets the CSR signed by the new CA keypair and the files mentioned earlier in this section are replaced. GSAN reloads the SSL socket on port 29000 and new clients connecting to GSAN see the user supplied CA.

Security Scanners would now show signed certificates on the port, and clients, proxies, and Data Domain will have to re-register to get the new CA.

Limitations

The Avamar session security features are subject to some limitations:

• Clients
  • Session security features cannot be used with any of the following Avamar clients:
    • Avamar cluster client for Solaris on Veritas Cluster Server
    • Avamar client for Solaris in Solaris clusters
• Other products
  • The use of NTP time synchronization of the Avamar server, Avamar clients, and the Data Domain system (if applicable) is encouraged. If the time is not synchronized, it could result in registration and backup/restore failure due to certificate validity and expiration times. Changing the time zone on a host may have a similar impact and may require certificate regeneration.
• Secure Token
  • Secured Token Authentication does not work under the following conditions:
    • The client machine is behind a Network Address Translation (NAT) firewall device
    • The client's hostname is a virtual name that is different from the FQDN resolved from its IP address
    • The client machine has multiple IP interfaces and each resolves to a different Fully Qualified Domain Name (FQDN). See the following KB for more information: KB 000056252 | Avamar: Back up to Data Domain failed with message "DDR_GET_AUTH_TOKEN" due to too many IP addresses

Session Security Change Planning

Before doing a change to the Session Security settings, the following steps can be done to have the opportunity to restore the previous configuration or certificates prior to making any changes.

Remember that if the Avamar internal root CA is changed, clients, proxies, and Data Domain must re-register. Depending on the size of the environment (number of clients, proxies, and Data Domains) this can be a cumbersome task spanning a few days.

The use-case would be if certificates are regenerated, and now there are registration and backup failures.

With the assumption that certificates are not expired or about to, and they are regenerated maybe by accident, the following steps offer some guidance on how to prevent being in a data loss or data unavailability situation.

Get the current Session Security settings and note them down:

enable_secure_config.sh --showconfig

Make a copy of the Avamar keystore:

cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original

Assume that certificates are now regenerated, either using the Session Security AVP or CLI methods.

This means that the Avamar keystore has changed, and the GSAN certificates re-signed.

The original Avamar keystore can simply be moved back into place:

cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore

Regenerate the GSAN certificates:

enable_secure_config.sh --certs

Restart MCS and Backup Scheduler:

mcserver.sh --restart --force
dpnctl start sched

This reinstates the original Avamar internal root CA which clients, proxies, and Data Domain were already trusting.

Troubleshooting

Most of the time, changing the Session Security settings or regenerating certificates is straightforward.

This section aims to address how to get everything working again after certificates are regenerated or settings changed.

Local Flushes

In the scenario in which verifypeer is enabled, when all Avamar certificates are regenerated, the client certificates that the Avamar server's avtar and avmgr use are not immediately updated.

This means, when MCS runs a scheduled flush (backup of the MCS configuration to GSAN) it will fail due to a TLS handshake failure. This is because the client certificates for avtar running on the Avamar server have not gotten the updated Avamar internal root CA yet and new set of signed client certificates.


Replication

In the scenario in which verifypeer is enabled on the replication destination, and certificates are regenerated on the destination then a similar approach from the 'Local Flushes' section above must be taken.

First, ensure that the replication destination Avagent is registered so that it can accept replication workorders.

On the destination, check the Avagent log at the following location:

/usr/local/avamar/var/client/avagent.log

A healthy log might look like this:

2024-02-22 15:31:57 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:31:57 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:31:57 avagent Info <5996>: Sleeping 15 seconds
2024-02-22 15:32:12 avagent Info <40019>: Checking certificate status.
2024-02-22 15:32:12 avagent Info <43701>: agent_message::resolve_client_ip ping to MCS avamar.lab:10.x.x.x using local IP:10.x.x.x failed, timed out on receive


2024-02-22 15:32:12 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:32:12 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:32:12 avagent Info <5996>: Sleeping 15 seconds

When going farther back in the log, there may be a recent successful re-registration:

2024-02-22 15:09:00 avagent Info <7502>: Registration of client /MC_SYSTEM/avamar.lab with MCS avamar.lab:30001 successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1008 Replicate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1038 vmir successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1046 Migrate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1051 Tiering successful.
2024-02-22 15:09:00 avagent Info <5619>: Registration of client and plugins complete.
2024-02-22 15:09:00 avagent Info <5996>: Sleeping 60 seconds

An unhealthy log with registration issues caused by certificate changes may look like this:

2024-02-22 15:04:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:04:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:04:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:05:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:05:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:05:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:06:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:06:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.

In this instance, in order to forcefully re-register Avagent with MCS immediately, the following steps must be taken:

Get the MC_SYSTEM account name, which will likely be the Avamar FQDN:

mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'

example:
root@avamar:/usr/local/avamar/lib/#: mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
avamar.lab

Deactivate the MC_SYSTEM account:

mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false

example:
mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false

Re-register the MC_SYSTEM account:

/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM

example:
/etc/init.d/avagent register avamar.lab /MC_SYSTEM

After the registration is successful, Avagent can accept replication on the destination.

Now, on the source Avamar if verifypeer is enabled on the replication destination Avamar we must regenerate the client certificates used to connect to the destination Avamar.

Remove the existing destination Avamar certificates folder from the source Avamar ssh session:

rm -r /usr/local/avamar/etc/<destination_avamar_ip_address>

rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>

Regenerate the client certificates:

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address>

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> --sysdir=/usr/local/avamar/etc/client

Communication to the destination Avamar can be tested from the Source Avamar ssh command-line:

avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192

Client Registration

Backups may be attempted after changing the Session Security settings or regenerating the certificates.

This may lead to finding many agent-based clients in 'Waiting-Client' status until failing to back up with 'Timed-Out Start'.

After the new certificates are regenerated, it should take about 23 hours for the client to automatically attempt to re-register.

The following command can be used on the Avamar server to send an invitation for agent-based clients to re-register with the Avamar MCS.

mccli client re-register-all

The command may take some time depending on the number of clients, as it sends an invitation to each one in sequential order. Consider running the command in the background in case the ssh session times out.

nohup mccli client re-register-all &

Note that this may not work to re-register all agent-based clients, and some may need to be re-registered manually.

The manual process for re-registering a client on Windows would be to:

• Remove the contents of the following directory which contains the old client certificates:

  • "C:\Program Files\avs\etc"

• Restart the "Backup Agent" service

The manual process for re-registering a client on Linux would be to:

• Remove the contents of the following directory which contains the old client certificates:

  • /usr/local/avamar/etc

• Restart the Avagent service:

  • service avagent restart

Rebooting the client machine can also be done to try and trigger a full re-registration.

Note that name resolution plays an important role in registering clients when Session Security is enabled, make sure that the clients can perform a forward and reverse DNS lookup of the Avamar server and vice-versa. This can be achieved either by configuring DNS A records or hosts entries on the client.

Avamar does not provide any sort of script that can reach out to every attached client to perform a manual re-registration, the previously mentioned mccli command is the closest to that.

Proxy Registration

Virtual Machines that are backed up to Avamar using proxies are somewhat at an advantage when it comes to post session security changes, as there are usually many less proxies than agent-based clients.

Proxies should also attempt an automatic re-registration within 23 hours, but it may be easier and faster to re-register them immediately.

There are a few options available to try a force a re-registration on the proxies.

The first option can be to reboot the proxies with the following command:

mccli mcs reboot-proxy --all

The second option would be to use the Goav tool to manage the proxies.

Set the proxy password for the Goav tool so it can log in to the proxies whenever it must. The following command does not change the OS password of the proxy, it simply stores the password encrypted so that the Goav tool can use it to log in to the proxy whenever it must over ssh.

./goav proxy set-password

Perform an Avagent restart on all attached proxies:

./goav proxy exec "service avagent restart"

To check the Avagent log in the proxy to see if a successful re-registration occurred, run the following command:

./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"

Successful output may look like the following:

============== proxy.lab.emc.com =========================
Executing grep -i registration /usr/local/avamarclient/var/avagent.log on proxy.lab.emc.com
2024-02-23 17:54:06 avagent Info <18918>: Registration: Processing secure registration with the MCS.
2024-02-23 17:54:06 avagent Info <18923>: Registration: Certificate files are present.
2024-02-23 17:54:09 avagent Info <5470>: Updating registration information with the MCS (10.x.x.x), paging enabled
2024-02-23 17:54:09 avagent Info <7501>: Client registration updated 3cbe29134da771ac547b7105743e66633ff12d40 10.x.x.x(1704339590)
2024-02-23 17:54:09 avagent Info <7502>: Registration of client /clients/proxy.lab.emc.com with MCS 10.x.x.x:30001 successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1019 vmwfilel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3019 vmwfilew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1016 vmimagel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3016 vmimagew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1001 Unix successful.
2024-02-23 17:54:09 avagent Info <5619>: Registration of client and plugins complete.

The third option is to ssh to the proxy and run the initialization script:

/usr/local/avamarclient/etc/initproxyappliance.sh start

Data Domain Sync

After the Session Security settings are changed or certificates regenerated on Avamar, the Data Domain will have to be re-synced, or SSL connection reestablished.

The following KB article covers this scenario, and how to exchange the new certificates with Data Domain.

Avamar: DD Showing Red in Avamar AUI and or user interface (Resolution Path)

It is strongly advised handling Avamar and Data Domain SSL troubleshooting with the Goav tool.

With Goav the Data Domain SSL connection with Avamar can be automatically diagnosed and resolved, see the following KB with more information:

Avamar: Information About Goav dd check-ssl Feature

Run the following command to automatically fix Avamar and Data Domain certificates:

./goav dd check-ssl --fix