Veritas NetBackup™ Troubleshooting Guide
- Introduction
- Troubleshooting procedures
- Troubleshooting NetBackup problems
- Troubleshooting vnetd proxy connections
- Troubleshooting security certificate revocation
- Verifying host name and service entries in NetBackup
- Frozen media troubleshooting considerations
- Troubleshooting problems with the NetBackup web services
- Resolving PBX problems
- Troubleshooting problems with validation of the remote host
- About troubleshooting Auto Image Replication
- Using NetBackup utilities
- About the NetBackup support utility (nbsu)
- About the NetBackup consistency check utility (NBCC)
- About the robotic test utilities
- Disaster recovery
- About disk recovery procedures for UNIX and Linux
- About clustered NetBackup server recovery for UNIX and Linux
- About disk recovery procedures for Windows
- About clustered NetBackup server recovery for Windows
- About recovering the NetBackup catalog
- About NetBackup catalog recovery and OpsCenter
- About recovering the entire NetBackup catalog
- About recovering the NetBackup catalog image files
- About recovering the NetBackup relational database
Unable to logon to the NetBackup Administration Console after external CA configuration
Review the troubleshooting following scenarios.
For information on the external CA support in NetBackup, refer to the NetBackup Security and Encryption Guide.
If the vnetd service is down on the host to which the NetBackup Administration Console is connecting
Check if the services are up on the host and try logging in again.
If external certificate's private key is not available or is in an incorrect format, error VRTS-28678 is displayed.
Check if the path provided for the ECA_PRIVATE_KEY_PATH configuration option is valid (it should not be empty).
Check if the path provided for ECA_PRIVATE_KEY_PATH is accessible and also if the private key file has required access permissions.
Provide a valid private key and try logging in again.
In case of Windows certificate store, do the following:
Run the certlm.msc command.
In case certlm.msc is not working, you can access the Windows certificate store by running the mmc.exe command. Go to .
Open the certificate by double clicking it.
The certificate with private key should have a message stating that you have a private key corresponding to this certificate.
If the external certificate is not present while you establish the trust with the NetBackup Administration Console.
Check if the path provided for the ECA_TRUST_STORE_PATH configuration option is not empty.
Check if the path provided for ECA_TRUST_STORE_PATH is accessible and also if the CA certificate file has required access permissions.
Provide a valid external certificate and try logging in.
In case of Windows certificate store, do the following:
Check if the root CA certificate is added in the Windows Cert Store's Trusted Root Certificate Authorities.
Run certlm.msc command. In the certificate management window, open the store named Trusted Root Certificate Authorities. The Trusted Root Certificate Authorities store contains all the self-signed certificates that are trusted by that machine.
In case certlm.msc is not working, you can access the Windows certificate store by running mmc.exe. Go to .
Select certificates from left hand side.
Click
.Select computer account. Click Next.
Click
and then .Click
.Check if the root CA certificate in the certificate chain is present in the Trusted Root Certificate Authorities store.
If the root CA certificate is not present, do the following:
Click
.Select .PEM or .CRT or .CER file of the certificate and click
.
Note:
All the certificates should be imported in the local machine store and not in the current user store. You can verify the current store in the certificate management window.
Add a valid external CA certificate and try logging in.
If an external CA-signed certificate is not present or not accessible, the following error is displayed:
The host does not have external CA-signed certificate. The certificate is mandatory to establish a secure connection.
Check if the path provided for ECA_CERT_PATH in NetBackup configuration file is not empty.
Check if the path provided for ECA_CERT_PATH points to the entire certificate chain.
Check if the path provided for ECA_CERT_PATH is accessible and also if it has required access permissions.
Provide a valid external CA-signed certificate and try logging in.
In case of Windows certificate store, do the following:
Check if ECA_CERT_PATH contains the appropriate value: Windows Certificate Store Name\Issuer Name\Subject Name. Verify if the certificate exists in the Windows certificate store.
Run the certlm.msc command.
In case certlm.msc is not working, you can access the Windows certificate store by running the mmc.exe.
File > Add Remove Snap in.
Navigate to your certificate as per your input Windows Certificate Store Name\Issuer Name\Subject Name.
Open your certificate by double-clicking it.
Ensure that it is valid, has a private key, a correct issuer name, and a correct subject name.
If you are using $hostname in Subject name, check that certificate subject has fully qualified domain name of the host.
If this is not the case, either change the ECA_CERT_PATH or put the right certificate in Windows certificate store and then try logging in.
Certificate revocation list (CRL) is not signed by a trusted authority.
This may occur at the time of login if the master server was configured to use NetBackup certificates and later it was enabled to use external certificates and vice versa. So the NetBackup Administration Console starts using the new CRL if you click Activity Monitor, locks the screen, tries to login again or in the periodic checks after every 1 hour, the certificate revocation status verification fails.
To fix this issue, you need to close the console and login again so that the peer host's certificate and the CRL are in sync.
If logging in again does not fix the issue then the reason can be the new CRL was not downloaded.
Run following command after correcting the CRL format:
UNIX: /usr/openv/netbackup/bin/nbcertcmd -updateCRLCache
Windows: install_path\Veritas\Netbackup\bin\nbcertcmd -updateCRLCache
The revocation status of the host certificate cannot be verified using the CRL, because the CRL format is not valid.
This error can occur if a delta CRL is used.
NetBackup does not support delta CRLs, so you need to use non-delta CRLs.
Run following command after correcting the CRL format:
UNIX: /usr/openv/netbackup/bin/nbcertcmd -updateCRLCache
Windows: install_path\Veritas\Netbackup\bin\nbcertcmd -updateCRLCache
The certificate of the host name is revoked.
If the certificate was revoked in error, reissue a certificate for the host.
If the certificate was revoked intentionally, a security breach may have occurred. Contact your security administrator.
The Certificate Revocation List could not be downloaded. Therefore the certificate revocation status could not be verified.
The possible causes include the following:
ECA_CRL_PATH is missing or has incorrect path.
The CRL file is missing. The CRL file is corrupted.
The CRL file could not be locked.
The CRL file could not be unlocked.
For more information, see the bpjava logs.
The Certificate Revocation List is not updated. Therefore the certificate revocation status could not be verified.
The possible causes include the following:
The next update date / time of the CRL is older than the current system date / time.
The CRL was valid at the time of login. The console was open and now the CRL has become invalid.
Ensure that the system time is correct.
In case the new CRL was not downloaded, run the following command
UNIX: /usr/openv/netbackup/bin/nbcertcmd -updateCRLCache
Windows: install_path\Veritas\Netbackup\bin\nbcertcmd -updateCRLCache
Unable to connect to the NetBackup Web Management Console service.
The possible causes include the following:
The NetBackup Web management Console service is down.
ECA_CERT_PATH does not point to the entire certificate chain.
Web service certificate's issuer and the issuer of the host certificate may not match.
If both the certificates are not issued by the same external CA, certificate trust verification fails.
Review the following:
It is mandatory to provide the path to the certificate file that contains the entire chain of certificates (except the root certificate).
If chain is not specified, the certificate trust verification fails and the console is not able to connect to the web service.
Ensure that the web server's certificate and the host certificate are issued by same external CA.