Dell PowerProtect Data Domain System Manager Login Failed While SSH Login Works – Troubleshooting an Expired HTTPS Certificate

Introduction

While managing a Dell PowerProtect Data Domain appliance, you may encounter a confusing situation where the same sysadmin credentials work successfully through SSH, but the credentials appear to fail when logging in to Data Domain System Manager (DD System Manager) through the web browser.

At first, this can look like a password or user-account problem.

However, the authentication credentials may be perfectly valid.

In this case, the actual root cause was an expired HTTPS certificate used by the Data Domain web interface.

This article explains how to troubleshoot this issue systematically and how to safely identify and resolve an expired HTTPS certificate.

Problem Statement

The issue was:

SSH login was successful, but DD System Manager login was not working with the same credentials.

The initial assumption could be:

Incorrect password
Locked user account
Incorrect user role
Web service disabled
HTTPS disabled
Authentication configuration problem

Instead of immediately changing the password, we verified each layer from the Data Domain CLI.

Environment

The troubleshooting was performed on:

Platform: Dell PowerProtect Data Domain
DDOS: 7.10.1.20
Administrative account: sysadmin
Access method working: SSH
Management interface: DD System Manager
HTTPS port: 443

The Data Domain CLI confirmed that the appliance was running DDOS 7.10.1.20.

Step 1 – Verify the User Account

The first step was to verify whether the sysadmin account was enabled and had the correct administrative role.

Run:

user show list

The output showed:

Name       Uid   Role    Last Login From   Last Login Time            Status
--------   ---   ------  ---------------   ------------------------   -------
sysadmin   100   admin   <management-IP>   <date/time>                enabled
Security   500   security <unknown>        <date/time>                enabled
DDboost    501   none    <management-IP>   <date/time>                enabled

The important information was:

sysadmin → Role: admin
sysadmin → Status: enabled

Therefore:

The user account was active and had the administrator role.

The CLI also showed a successful previous login for the sysadmin account, confirming that the account was being used successfully.

Step 2 – Verify SSH and HTTPS Services

Next, we checked the Data Domain management services.

Command:

adminaccess show

The important output was:

Service       Enabled
-----------   -------
ssh           yes
scp           yes
telnet        no
ftp           no
ftps          no
http          no
https         yes
web-service   yes

This immediately confirmed that:

SSH was enabled.
HTTPS was enabled.
The web service was enabled.
HTTP was disabled, which is normal for a secure configuration.

The HTTPS service was configured to use port:

The CLI output confirms HTTPS and web-service were enabled and that the HTTPS port was 443.
At this point, the account and web service both appeared healthy.

So the next area to investigate was SSL/TLS certificate validity.

Step 3 – Check the HTTPS Certificate

This was the key troubleshooting step.

Run:

adminaccess certificate show

The output showed:

Subject                Type   Application   Valid From        Valid Until
---------------------  ----   -----------   ----------------  ----------------
<DD-hostname>          host   https         Jun 3 2025        Jul 3 2026
<DD-hostname>          ca     trusted-ca     Jul 3 2024        Jul 2 2030

The important observation was:

Application: HTTPS
Valid Until: July 3, 2026

The troubleshooting was performed on August 14, 2026.

Therefore, the HTTPS host certificate had already expired.

The CA certificate itself was still valid until 2030.

Root Cause

The root cause was:

The HTTPS host certificate used by DD System Manager had expired.

This explains why SSH continued to work while the web interface was experiencing authentication/access problems.

SSH and HTTPS are separate management services.

SSH

SSH
 ↓
TCP 22
 ↓
SSH authentication
 ↓
sysadmin

DD System Manager

Web Browser
 ↓
HTTPS
 ↓
TCP 443
 ↓
Web Service
 ↓
DD System Manager
 ↓
Authentication

Therefore, a healthy SSH connection does not necessarily mean that the HTTPS management interface is healthy.

Step 4 – Generate a New Self-Signed Certificate

Because the existing HTTPS certificate was expired, a new self-signed certificate was generated.

Command:

adminaccess certificate generate self-signed-cert

The Data Domain confirmed:

New certificates have been generated.

The command execution and successful certificate generation are recorded in the troubleshooting session.

Step 5 – Verify the New Certificate

After generating the certificate, verify it again:

adminaccess certificate show

The new certificate showed a new validity period:

Application: HTTPS

Valid From:  July 14, 2026
Valid Until: August 14, 2027

The trusted CA certificate remained unchanged and continued to be valid until 2030.

This confirmed that the HTTPS host certificate had been successfully renewed.

Step 6 – Restart HTTPS Access

To make sure the web service loaded the newly generated certificate, HTTPS access was disabled and enabled again.

Commands:

adminaccess disable https

Then:

adminaccess enable https

The Data Domain confirmed:

HTTPS Access: disabled
HTTPS Access: enabled

The actual command execution is visible in the CLI session.

Step 7 – Test DD System Manager

After enabling HTTPS again, open the Data Domain System Manager:

https://<Data-Domain-IP>

or:

https://<Data-Domain-FQDN>

Then log in using the existing administrative credentials:

Username: sysadmin
Password: <existing password>

The important point is that the password did not need to be changed.

The issue was related to the expired HTTPS certificate.

Troubleshooting Flow

When SSH works but DD System Manager does not, use this troubleshooting sequence:

SSH Login Working?
        |
        v
Check User Account
        |
        v
user show list
        |
        v
Is sysadmin enabled?
        |
        v
Is Role = admin?
        |
        v
Check Web Services
        |
        v
adminaccess show
        |
        v
HTTPS enabled?
Web-service enabled?
        |
        v
Check Certificate
        |
        v
adminaccess certificate show
        |
        v
Is HTTPS certificate expired?
        |
       YES
        |
        v
Generate new certificate
        |
        v
adminaccess certificate generate self-signed-cert
        |
        v
Verify certificate
        |
        v
Restart HTTPS
        |
        v
adminaccess disable https
adminaccess enable https
        |
        v
Test DD System Manager

Important Lesson

One of the most important lessons from this incident is:

Do not immediately reset the password when SSH works but the web interface fails.

First determine which management layer is failing.

Check:

User account status
User role
SSH service
HTTPS service
Web service
HTTPS certificate
Certificate validity period
Browser/HTTPS connectivity
Authentication configuration

This approach prevents unnecessary password changes and reduces the risk of introducing another problem.

Useful Data Domain Commands

Check users

user show list

Check management services

adminaccess show

Check HTTPS certificates

adminaccess certificate show

Generate a new self-signed certificate

adminaccess certificate generate self-signed-cert

Restart HTTPS

adminaccess disable https
adminaccess enable https

Security Considerations

Before changing certificates on a production Data Domain, verify whether the appliance is integrated with other products or services that depend on certificate trust.

Examples include:

Dell PowerProtect Data Manager
Data Domain Management Center
Replication environments
Cyber Recovery
Backup applications
Monitoring systems
External certificate authorities

If the Data Domain uses a certificate issued by an enterprise CA, do not automatically replace it with a self-signed certificate. Follow your organization's certificate-management procedure.

For production environments, always consider:

Change management
Backup/DR dependencies
Certificate trust relationships
Maintenance windows
GxP/regulated-system requirements
Validation impact assessment where applicable
Documentation of the change

Conclusion

The key takeaway from this troubleshooting exercise is simple:

SSH working does not guarantee that DD System Manager will work.

In this case:

sysadmin account       → Enabled ✅
Administrator role     → Confirmed ✅
SSH                    → Working ✅
HTTPS service          → Enabled ✅
Web service            → Enabled ✅
HTTPS certificate      → Expired ❌
New certificate        → Generated ✅
HTTPS restarted        → Completed ✅
DD System Manager      → Working ✅

The issue was successfully resolved by identifying the expired HTTPS certificate, generating a new self-signed certificate, and restarting HTTPS access.

This is a good example of why a structured troubleshooting methodology is more effective than immediately changing credentials.

Recommended Checklist for Data Domain Administrators

Whenever you face:

"SSH works, but DD System Manager login doesn't work."

Remember:

User → Role → Service → HTTPS → Certificate → Authentication → Browser

Checking these layers in order will help you identify the root cause quickly and safely.

Search This Blog

Computer NetworKING & System Administrator