Summary: When the https certificate expires on a DD, it will cause weird issues when trying to access the web GUI. Generating a new cert will resolve the issue.
This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.
You might see 404 http errors or other apache web service errors when the certificate expires
There could be other errors such as resource unavailable
GUI is inaccessible in general
When the https certificate expires on a DD, it causes weird issues with Apache web server and will bring the GUI down and cause it to be inaccessible.
You will need the sysadmin credentials for any DDs/DDMC that have previously established trust with this DD. Make sure those credentials are available before attempting this procedure.
1. If this is a DD in an IDPA or Cyber Recovery Vault kind of setup, there might be considerations for how those systems monitor the DD using certificates. Their support may need to be engaged when the certificate is expired and then a new one is added.
This is not a concern for DDs in a DLm solution as the DLm does not require or use http or https access to communicate with the Data Domain. Certificate updates on the Data Domain may be performed without interruption of the DLm tape mount processing.
Check if the certificate is expired:
# adminaccess certificate show
If it is not expired, could be due to this issue:
Data Domain : After upgrading to DDOS / DDMC 7.1.x or later, GUI can’t be accessed anymore
If the certificate is expired, check the currently established trusts:
# adminaccess trust show
You’ll see the certificate for the current DD (by its hostname) and certificates of other DDs or DDMC. You will need the sysadmin passwords for any DDs/DDMCs in the trust pair to re-establish after generating a new cert.
Check to see if it is a self-signed cert or if the customer signs it with a Certificate Authority (CA)
# adminaccess certificate show imported-host application https
If this returns anything, customer signs the cert with a CA. Otherwise if there’s no imported host cert, the cert is self signed.
If the cert is self-signed, you can simply regenerate a new certificate with
# adminaccess certificate generate self-signed-cert regenerate-ca
If the cert is signed by external CA, you’ll need to generate a new Certificate Signing Request (CSR) which the customer will then pass to their CA to get signed and then import the signed cert back into the DD:
Data Domain : How to generate a Certificate Signing Request (CSR)
Once you have a new valid certificate, you will need to re-establish trust between any DDs that are using replication with the current DD and if there’s a DDMC that will require this as well.
For any DDs or DDMC with previously established trust, run this command to delete old trust and then re-establish trust with using the new cert on the current DD:
(This will ask for sysadmin password on the other DDs/DDMCs. Please ensure that you have them for all DDs/DDMCs or you can remove the trust for any DDs/DDMCs that have been decommissioned without adding them back. (Use the command without the “type mutual” when doing this.)
# adminaccess trust del host <hostname of other DD/DDMC> type mutual
then run this to establish new trust:
# adminaccess trust add host <hostname of other DD/DDMC> type mutual
For the above example, run the add and remove for ALL the other DDs/DDMCs in turn.
# adminaccess trust del host sc-dd2500-2.lss.emc.com type mutual
# adminaccess trust add host sc-dd2500-2.lss.emc.com type mutual
and if you do not need to re-add the trust back because this DD has been decommissioned:
# adminaccess trust del host dd690.dssupport.emea
Now that trust has been re-established, we need to restart the GUI services:
# adminaccess disable http
# adminaccess disable https
# adminaccess enable http
# adminaccess enable https
The GUI should be accessible