Avamar: Install or Replace Avamar Certificate Authority (CA) with User Supplied Certificate Authority (CA)
Summary: How to replace the default self-signed Management Console Service (MCS) root Certificate Authorities (CA) with its own CA for gsan/mcs/avagent.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
Background
Avamar exposes several ports with certificates installed on them.
The web servers on Avamar expose the following ports with ssl certificates:
When session security is enabled the following ports load ssl certificates:
When session security is enabled, backup clients load ssl certificates on the following ports:
This How-To kb article aims to describe the proper context in which to replace the Certificate Authority on the secure ports used when session security is enabled for client registration, backups, and replication.
Scenarios
First Scenario:
If you want to replace the Avamar web server certificates, see the following KB article:
000198691 | Avamar 19.2+ : Install signed web server certificates for avinstaller, aam/flr/dtlt, mcsdk, rmi, and apache aui
Second Scenario:
If you want to replace the certificates that are used for backups/replication/registration (gsan/mc root ca):
Follow the steps below to replace the Avamar CA with your own CA.
Session Security Background
From the Product Security Guide
Session security features
Avamar session security features are provided by the Avamar installation, Avamar Virtual Edition (AVE) configuration, upgrade workflow packages and stand-alone session security configuration workflow.
Session security features include security improvements for communications between Avamar system processes.
The Avamar system secures all communications between Avamar system processes by using session tickets. A valid session ticket is required before an Avamar system process accepts a transmission from another Avamar system 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 system process.
- The integrity of a session ticket is protected by encryption.
- Each Avamar system node separately verifies the session ticket signature.
- A session can be extended beyond the life of the session ticket when required.
Avamar server authentication
After installing the session security features, the Avamar system 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.
There is a supplemental KB article with more information about Session Security below:
000222278 | Avamar: Session Security
Check Session Security Settings
Log in to the Avamar server using ssh
As the root user, run the following command:
If any of the settings return true, session security is enabled.
If you need additional help changing session security settings see the following KB articles:
000222234 | Avamar: Manage Session Security Settings from CLI
000222279 | Avamar: Manage Session Security Settings with Avinstaller Installation Package (AVP)
Notes
Difference between replacing web server certs vs gsan/mcs root certs:
- Web server certs replaced using the aui.
- Web server certs can use public or internal chained ca.
- Web server certs install a leaf/server/end-entity certificate with its corresponding private key.
- Web server cert's server certificate has a basic constraint of CA: False, indicating that the certificate can NOT be used to issue further downstream CA certificates (like another intermediate CA)
- gsan/mcs root certs replaced using importcert.sh script on Avamar Utility Node.
- gsan/mcs root certs are CA certificates, NOT leaf/server/end-entity.
- gsan/mcs root certs have a basic constraint of CA: True
What is a basic constraint?
Basic Constraints is an X.509 Version 3 certificate extension and is used to identify the type of the certificate holder or subject.
If the certificate is a root CA or Intermediate CA, it is expected to have a Basic Constraints Extension with the CA boolean set to True. This would allow the certificate to sign other certificates and Certificate Revocation List (CRLs), validate the signature of issued certificates, and optionally set restrictions or constraints on the configuration of issued certificates.
If the certificate is an leaf/server/end-entity cert, it is expected to have a Basic Constraints Extension with the CA boolean set to False. An end-entity certificate cannot sign further downstream certificates.
When replacing the GSAN/MC root CA certs, they are replaced with another Certificate Authority (CA). Likely internal, since no publicly trusted CA would ever hand over their CA private key to an end customer.
Steps to Replace Avamar CA with User Supplied CA
1. Prepare your root/intermediate certificate files:
- private key: The private key corresponding to the furthermost downstream CA certificate that has the ability to issue certificates.
- 'server' cert: The furthermost downstream CA certificate in Privacy-Enhanced Mail (PEM) format that has the ability to issue certificates.
- chain cert: one file containing concatenated PEM formatted intermediate/root CA certificates to build a chain of trust.
2. Run the importcert.sh script as root user to install the new user supplied CA:
- Stop MCS and the backup scheduler.
- Verify key and certificate match.
- Verify that the chain file builds a chain of trust for the cert.
- Import the files into the Avamar keystore.
- Refresh the GSAN certificates.
- Start MCS
- Attempt to re-register all clients.
- Resync with data domain.
- Resume the backup scheduler service.
Example
Three files prepared
int_key.pem - internal intermediate CA private key in PKCS1 format
int_cert.crt - internal intermediate CA certificate
root_ca.crt - internal root CA certificate
int_key.pem
int_cert.crt
root_ca.crt
Installation
Post Installation
Once the installation script is complete, it may be required to re-register some agent-based clients manually and VMware proxies.
If you want to check the contents of the Avamar Keystore to see the result of running the script, run the following command:
Mcrsaroot should be a CA only alias with a basic constraint CA: True
Mcrsatls should be a full chained end entity certificate that is issued to the Avamar server by user supplied downstream CA
If you want to validate that the certificates were replaced, you can connect to the Avamar Utility Node as a secure client using openssl to grab the certificate contents for the gsan/mcs/registration ports.
Avamar exposes several ports with certificates installed on them.
The web servers on Avamar expose the following ports with ssl certificates:
Port Service 7778 Java Remote Method Invocation (RMI) 7779 Java Remote Method Invocation (RMI) 7780 Java Remote Method Invocation (RMI) 7781 Java Remote Method Invocation (RMI) 443 Apache Webserver 9443 MCSDK (MCS Developer Kit SOAP API) 8543 Tomcat/DTLT/EMT 7543 Avinstaller/Jetty
When session security is enabled the following ports load ssl certificates:
Port Service 29000 GSAN secure listening port 30001 Avagent/MCS secure registration port 30002 Avagent/MCS secure port (when replication destination is configured) 30003 Avagent/MCS secure registration port
When session security is enabled, backup clients load ssl certificates on the following ports:
Port Service 30002 Avagent/MCS secure listening port (backup client)
This How-To kb article aims to describe the proper context in which to replace the Certificate Authority on the secure ports used when session security is enabled for client registration, backups, and replication.
Scenarios
First Scenario:
If you want to replace the Avamar web server certificates, see the following KB article:
000198691 | Avamar 19.2+ : Install signed web server certificates for avinstaller, aam/flr/dtlt, mcsdk, rmi, and apache aui
Second Scenario:
If you want to replace the certificates that are used for backups/replication/registration (gsan/mc root ca):
Follow the steps below to replace the Avamar CA with your own CA.
Session Security Background
From the Product Security Guide
Session security features
Avamar session security features are provided by the Avamar installation, Avamar Virtual Edition (AVE) configuration, upgrade workflow packages and stand-alone session security configuration workflow.
Session security features include security improvements for communications between Avamar system processes.
The Avamar system secures all communications between Avamar system processes by using session tickets. A valid session ticket is required before an Avamar system process accepts a transmission from another Avamar system 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 system process.
- The integrity of a session ticket is protected by encryption.
- Each Avamar system node separately verifies the session ticket signature.
- A session can be extended beyond the life of the session ticket when required.
Avamar server authentication
After installing the session security features, the Avamar system 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.
There is a supplemental KB article with more information about Session Security below:
000222278 | Avamar: Session Security
Check Session Security Settings
Log in to the Avamar server using ssh
As the root user, run the following command:
enable_secure_config.sh --showconfig
If any of the settings return true, session security is enabled.
If you need additional help changing session security settings see the following KB articles:
000222234 | Avamar: Manage Session Security Settings from CLI
000222279 | Avamar: Manage Session Security Settings with Avinstaller Installation Package (AVP)
Notes
Difference between replacing web server certs vs gsan/mcs root certs:
- Web server certs replaced using the aui.
- Web server certs can use public or internal chained ca.
- Web server certs install a leaf/server/end-entity certificate with its corresponding private key.
- Web server cert's server certificate has a basic constraint of CA: False, indicating that the certificate can NOT be used to issue further downstream CA certificates (like another intermediate CA)
- gsan/mcs root certs replaced using importcert.sh script on Avamar Utility Node.
- gsan/mcs root certs are CA certificates, NOT leaf/server/end-entity.
- gsan/mcs root certs have a basic constraint of CA: True
What is a basic constraint?
Basic Constraints is an X.509 Version 3 certificate extension and is used to identify the type of the certificate holder or subject.
If the certificate is a root CA or Intermediate CA, it is expected to have a Basic Constraints Extension with the CA boolean set to True. This would allow the certificate to sign other certificates and Certificate Revocation List (CRLs), validate the signature of issued certificates, and optionally set restrictions or constraints on the configuration of issued certificates.
If the certificate is an leaf/server/end-entity cert, it is expected to have a Basic Constraints Extension with the CA boolean set to False. An end-entity certificate cannot sign further downstream certificates.
When replacing the GSAN/MC root CA certs, they are replaced with another Certificate Authority (CA). Likely internal, since no publicly trusted CA would ever hand over their CA private key to an end customer.
Steps to Replace Avamar CA with User Supplied CA
1. Prepare your root/intermediate certificate files:
- private key: The private key corresponding to the furthermost downstream CA certificate that has the ability to issue certificates.
- 'server' cert: The furthermost downstream CA certificate in Privacy-Enhanced Mail (PEM) format that has the ability to issue certificates.
- chain cert: one file containing concatenated PEM formatted intermediate/root CA certificates to build a chain of trust.
2. Run the importcert.sh script as root user to install the new user supplied CA:
importcert.sh <private key> <cert> <chain>The script will:
- Stop MCS and the backup scheduler.
- Verify key and certificate match.
- Verify that the chain file builds a chain of trust for the cert.
- Import the files into the Avamar keystore.
- Refresh the GSAN certificates.
- Start MCS
- Attempt to re-register all clients.
- Resync with data domain.
- Resume the backup scheduler service.
Example
Three files prepared
int_key.pem - internal intermediate CA private key in PKCS1 format
int_cert.crt - internal intermediate CA certificate
root_ca.crt - internal root CA certificate
int_key.pem
root@ser-ave03:/home/admin/#: cat int_key.pem -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEAorFbO4McgCv8tFrQVyzcjBQdOAT/bYVNG5SjWH895MHM9OFU B2sQcCTvGJRdSXEheuqHtRVWt761CReXk+yhf51XGtU+0OQdPWecHeSyWfzsLihy ZfCRYcoSP7OW6IAOiigWTZqroZc2jWOygZevyM8HPmpmOa7C2TYCHZNgAQnbw+IU XRDR/Yofsj+IjOit+Fw0zAE2GBm6pViNIv1nHwxTtXkjlu9g4qcHML1/0WkJ2d+p lmnE8qMZtdzOSWZeuBDiOsyTHbjAZFhDetWOjcUZ8z7zmvTjtgSMcSJCQnuNL9Y2 [key_contents_retracted_for_privacy] w1JY6IaQO6GhzLInet2uguuZ9rBBnYxcsz9/PV6Y+ZMTGX1ySLXAhfht0rtfN3qq 3SFzXagwB/v42rEHDRI7Tin7v5oNpD5hWSTwW9jIFikJJZuYCMagwH+to6Pa6CFY AOdHAoGAGCvK9QjJW5BRHAwjgzH3aQijKK9lKtQH4v5YJsEqQK4lFg3S8m6KxgTA XyMzkOFx5+3CFRrXCbNyS3hLDen7IMAZbY35QhvW2DO0Sow+t3dVOxk26RGeAopo ZmemuZ3TR4Esqrd9rdAwHy/YwJ1ZWcLRQmfab4MoQPmK0iuSA6A= -----END RSA PRIVATE KEY-----
int_cert.crt
root@ser-ave03:/home/admin/#: cat int_cert.crt -----BEGIN CERTIFICATE----- MIIDRzCCAi+gAwIBAgIQfpAycyHdgHTR+JiDuTZLNzANBgkqhkiG9w0BAQsFADAX MRUwEwYDVQQDDAx0b255X3Jvb3RfQ0EwHhcNMjIxMDIxMTQ1ODU2WhcNMjUwMTIz MTQ1ODU2WjAfMR0wGwYDVQQDDBR0b255X2ludGVybWVkaWF0ZV9DQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKxWzuDHIAr/LRa0Fcs3IwUHTgE/22F TRuUo1h/PeTBzPThVAdrEHAk7xiUXUlxIXrqh7UVVre+tQkXl5PsoX+dVxrVPtDk HT1nnB3ksln87C4ocmXwkWHKEj+zluiADoooFk2aq6GXNo1jsoGXr8jPBz5qZjmu wtk2Ah2TYAEJ28PiFF0Q0f2KH7I/iIzorfhcNMwBNhgZuqVYjSL9Zx8MU7V5I5bv YOKnBzC9f9FpCdnfqZZpxPKjGbXczklmXrgQ4jrMkx24wGRYQ3rVjo3FGfM+85r0 47YEjHEiQkJ7jS/WNsr/i7+ID/OUsf9yemLW00tfLEXSgWcaVEHhH+cCAwEAAaOB hjCBgzAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBTaUhUnUx2JL/SGVARyaGuQESLC 7DBHBgNVHSMEQDA+gBRXocE7ZbX0UU6YbhaT7hYG5N+zeKEbpBkwFzEVMBMGA1UE AwwMdG9ueV9yb290X0NBggkA1Ru7coWIaxYwCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBCwUAA4IBAQAWTZjFYHIfz6r8N9EtMqweTOfSdNAPfwEKLmIfKJq27oYaE2Il +2xCWBlsa4tz95Rr6Ve0gLT1NmFZki81GcikTS1NG/qeRmPq4orNrMz3HGmU2C/F lFnNOvuJeg8n/0Bl9SWijs4t95ddFty99vU3yWvUrnD/tfwfuMm4v2txRHGaZfSn 90oR6Iy/RwZ3+khcw7NojZ8/UUMHSGX+wk/Lo9pTWM6rxDgDYBGI8z2YLmuiBniO tU8ByLnwCpyFjvho5/ja+rwrs4Qw50n0ZTSbRyoOHRdr73hG8g7sZaReLlq/As9u +CBakbNCeywsmUDVrFifGGkVoadBjjGUpYkC -----END CERTIFICATE-----
root@ser-ave03:/home/admin/#: openssl x509 -noout -text -subject -issuer -in int_cert.crt | grep "CA:\|subject\|issuer"
CA:TRUE
subject= /CN=tony_intermediate_CA
issuer= /CN=tony_root_CA
root_ca.crt
root@ser-ave03:/home/admin/#: cat root_ca.crt -----BEGIN CERTIFICATE----- MIIDODCCAiCgAwIBAgIJANUbu3KFiGsWMA0GCSqGSIb3DQEBCwUAMBcxFTATBgNV BAMMDHRvbnlfcm9vdF9DQTAeFw0yMjEwMjExNDUyMzZaFw0zMjEwMTgxNDUyMzZa MBcxFTATBgNVBAMMDHRvbnlfcm9vdF9DQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANJrB+YHwQPKWdt19nH5IaxEwz198gfJvfVtoG/Qt7HKiDHb6XAa g7nP6MHLZmbNdIv2FB9S9UrOARgOZuxJ4EvqP2Q188ArNFnkUZoo1ylO2JyZ2f7D C21eOGfuupvczdYlB/Tklfs207RIPhEvds5JrMEKmPrP1g8O3kCpiPqoi1Ul+0AG WW8k/EViEaZgsmhMzd3TWm9vcrO5lxzeFnSO8DUL/pAkbvngEErROe02dWayZ3R9 y+tZQ0hDNm0e3qp7iSaDeEOXtXAnr6j/126qaI+q2Mk3/NQpjxYjKuYrW/8dcIOZ LIuISYIpcbc2WU/p0sQVwDo93bBUd1IBbuUCAwEAAaOBhjCBgzAMBgNVHRMEBTAD AQH/MB0GA1UdDgQWBBRXocE7ZbX0UU6YbhaT7hYG5N+zeDBHBgNVHSMEQDA+gBRX ocE7ZbX0UU6YbhaT7hYG5N+zeKEbpBkwFzEVMBMGA1UEAwwMdG9ueV9yb290X0NB ggkA1Ru7coWIaxYwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IBAQAu+Wgs yWIQT4jIaVX0ddyvrTyXxeMgLovmRyOHC+sa7BPhoyOoGPDlBkaS0s1VABtAoiml Ioqf4UrYsVXFFvrhfTny0FE9Ryw4Q3Az0msj0gELfMuHWkKitW+d/z578g8ngxC4 WDOMwbIzHPa2TbIFoH+plNhnbpxWZj0WRaUBN9uW5U7lG/+OCMgs5+/kjPqrhfyy yNC2/2AgO1QhyZ7wcEltQ5iTQLfni3NVzbLGImOWCbNgKeKYn2pApq5EwUIvyqK5 KPFBXMelDDGcbieJW+7QbDtSnsghsp5i0R6bG5DElYfYODECQMdq3v5/dk/7oDqT 9WHdPFSNlZp0AVtQ -----END CERTIFICATE-----
root@ser-ave03:/home/admin/#: openssl x509 -noout -text -subject -issuer -in root_ca.crt | grep "CA:\|subject\|issuer"
CA:TRUE
subject= /CN=tony_root_CA
issuer= /CN=tony_root_CA
Installation
root@ser-ave03:/home/admin/#: importcert.sh int_key.pem int_cert.crt root_ca.crt The script will re-generate and replace Avamar RootCA. The mcs will be restarted, and ddboost service on datadomain will be restarted if there are datadomains attached. Do you want to continue N/y? [N]:Y 0. Stop backup scheduler Identity added: /home/admin/.ssh/admin_key (/home/admin/.ssh/admin_key) dpnctl: INFO: Suspending backup scheduler... dpnctl: INFO: Backup scheduler suspended. 1. Stop MC Server === BEGIN === check.mcs (poststart) check.mcs passed === PASS === check.mcs PASSED OVERALL (poststart) Stopping REST API Service... REST API Service stopped. Administrator Server shutdown initiated. Stopping Administrator Server at Tue Oct 25 20:19:46 GMT 2022 ... Administrator Server stopped at Tue Oct 25 20:19:48 GMT 2022. === Stop Avamar Certificate Service === Avamar Certificate Service stopped. Stopping the database server. Database server stopped. 2. Vefify key cert if match Key cert matched OK 3. Verify cert by chain Verify OK 4. Import key&cert&chain into keystore Import to keystore OK 5. Refresh tls cert Refresh tls OK 6. Refresh gSAN cert 7. Start MC server Starting the database server. Waiting for postmaster to start ..Started Start MCDB: processing time = 2 s. Check MCS: processing time = 4 s. INFO: Starting messaging service. INFO: Started messaging service. Start Message Broker: processing time = 11 s. === BEGIN === check.mcs (prestart) check.mcs passed === PASS === check.mcs PASSED OVERALL (prestart) Starting Administrator Server at Tue Oct 25 20:20:39 GMT 2022 ... Upgrade MCS Preference: processing time = 196ms Upgrade MCDB: processing time = 436ms Check node list: processing time = 659ms Prepare MC SSL Properties: processing time = 1ms Init node: processing time = 340ms Install service: com.avamar.mc.prefs.MCSPreferencesService, processing time = 9ms Install service: com.avamar.mc.message.MessageEventService, processing time = 11ms Event Size: 18548 Install service: com.avamar.mc.event.EventService, processing time = 5619ms Install service: com.avamar.mc.jms.push.JmsPushService, processing time = 98ms Install service: com.avamar.mc.dpn.DPNProxyService, processing time = 7262ms Install service: com.avamar.mc.datatap.MCDataTapService, processing time = 9ms Install service: com.avamar.mc.cm.ClusterManagerService, processing time = 6ms Install service: com.avamar.mc.wo.WorkOrderSchedulingService, processing time = 305ms Install service: com.avamar.mc.sch.ScheduleService, processing time = 229ms Install service: com.avamar.mc.um.UserManagerService, processing time = 49ms Install service: com.avamar.mc.ldap.LdapManagerService, processing time = 105ms Install service: com.avamar.mc.datadomain.DataDomainService, processing time = 414ms Install service: com.avamar.mc.cr.ClientRegistryService, processing time = 4054ms Install service: com.avamar.mc.burm.BackupRestoreManagerService, processing time = 67ms Initiated VC: /myvc.dell.com Ver: null-null. (Total time - 50359 ms) VmwareService is ready. (Total time - 50362 ms) Install service: com.avamar.mc.vmware.VmwareService, processing time = 53459ms Wait VC cache pool synchronized done for vc /nc-ave01.dell.com at Tue Oct 25 20:21:54 GMT 2022 Total time(ms) - 0 Install service: com.avamar.mc.pdm.ProxyDeploymentManagerService, processing time = 37ms Install service: com.avamar.mc.mon.MonitorService, processing time = 457ms Install service: com.avamar.mc.mcsm.MCSManagerService, processing time = 135ms Install service: com.avamar.mc.lm.LicenseManagerService, processing time = 118ms Install service: com.avamar.mc.rpt.ReportService, processing time = 180ms Install service: com.avamar.mc.ws.MCWebServices, processing time = 154ms Install service: com.avamar.mc.ws.MCJettyService, processing time = 1272ms Install service: com.avamar.mc.repl.ReplicationService, processing time = 87ms Install service: com.avamar.mc.st.SessionTicketService, processing time = 1171ms Install service: com.avamar.mc.ras.McEbmsService, processing time = 3698ms Install service: com.avamar.mc.migration.MigrationService, processing time = 56ms Start service container: processing time = 79083ms log4j:WARN No appenders could be found for logger (org.apache.axiom.util.stax.dialect.StAXDialectDetector). log4j:WARN Please initialize the log4j system properly. Init crontab: processing time = 4075ms Update axion system table: processing time = 4ms Update connect emc email subject: processing time = 12ms Administrator Server started at Tue Oct 25 20:22:06 GMT 2022. Start MC Java Process: processing time = 88 s. INFO: Starting Data Domain SNMP Manager.... INFO: Connecting to MCS Server: ser-ave03 at port: 7778... INFO: Successfully connected to MCS Server: ser-ave03 at port: 7778. INFO: No trap listeners were started, Data Domain SNMP Manager didn't start. Other Task: processing time = 7 s. Starting REST API Service........ REST API Service started. Start MC Rest: processing time = 16 s. === Start Avamar Certificate Service === Avamar Certificate Service started. 8. Re-register all clients 0,22237,Client invited to activate with server. Attribute Value --------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- summary Partial-sucessfullly activiated clients. , succeed activated clients: client1.dell.com ser-ave03 client2.dell.com , failed activated clients: ser-ave04, caused by Unable to contact: /clients/ser-ave04 on port: 28009 client3.dell.com, caused by Unable to contact: /clients/client3.dell.com on port: 28002 client4.dell.com, caused by Unable to contact: /clients/client4.dell.com on port: 28002 10. Start backup scheduler Identity added: /home/admin/.ssh/admin_key (/home/admin/.ssh/admin_key) dpnctl: INFO: Resuming backup scheduler... dpnctl: INFO: Backup scheduler resumed. dpnctl: INFO: No /usr/local/avamar/var/dpn_service_status exist.
Post Installation
Once the installation script is complete, it may be required to re-register some agent-based clients manually and VMware proxies.
If you want to check the contents of the Avamar Keystore to see the result of running the script, run the following command:
keytool -list -v -keystore /usr/local/avamar/lib/avamar_keystore -storepass $(avlockbox.sh -r keystore_passphrase)Aliases:
Mcrsaroot should be a CA only alias with a basic constraint CA: True
keytool -export -keystore /usr/local/avamar/lib/avamar_keystore -storepass $(avlockbox.sh -r keystore_passphrase) -alias mcrsaroot -rfc | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"example
Issuer: CN=tony_root_CA
Subject: CN=tony_intermediate_CA
CA:TRUE
Mcrsatls should be a full chained end entity certificate that is issued to the Avamar server by user supplied downstream CA
keytool -export -keystore /usr/local/avamar/lib/avamar_keystore -storepass $(avlockbox.sh -r keystore_passphrase) -alias mcrsatls -rfc | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"example
Issuer: CN=tony_intermediate_CA
Subject: C=US, ST=California, L=Irvine, O=EMC Corp, OU=BRS Division, CN=Avamar Server RSA TLS, CN=ser-ave03.dell.com
CA:FALSE
If you want to validate that the certificates were replaced, you can connect to the Avamar Utility Node as a secure client using openssl to grab the certificate contents for the gsan/mcs/registration ports.
Port Certificate 29000 /home/admin/chain.pem (exported PEM copy of mcrsaroot) 30001 mcsrsatls (chained) 30002 new avamar client certificate 30003 mcrsatls (chained)
openssl s_client -connect localhost:29000 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"
openssl s_client -connect localhost:30001 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"
openssl s_client -connect localhost:30002 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"
openssl s_client -connect localhost:30003 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | egrep "Subject:|Issuer:|CA:"
Troubleshooting
If you encounter the following error during the script, it is likely due to trying to install an end-entity certificate instead of a CA capable of certificate issuance.
5. Refresh tls cert Refresh tls ERROR
If port 30002 on the Avamar Utility Node still shows the old certificates after the script completes successfully, restart Avagent.
service avagent restart
Affected Products
AvamarArticle Properties
Article Number: 000204629
Article Type: How To
Last Modified: 30 May 2024
Version: 6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.