Credential and Certificate Rotation in Redis Software – Redis Knowledge Base

Redis Software provides robust tools for managing user credentials, database passwords, API keys, and TLS certificates. This article explains how to rotate credentials and certificates, troubleshoot common rotation issues, and apply best practices for secure operations. Key sections include Credential Rotation Policies and Procedures, Certificate Management and Rotation, and Troubleshooting Tips

Credential Management in Redis Software

User Credentials

Redis Software manages credentials for console, admin/API users, and individual databases. All credentials are securely stored, with support for Role-Based Access Control (RBAC) and Access Control Lists (ACLs).
REST API endpoints require basic authentication, and credentials for both admin and regular users are documented in the Redis Software REST API reference.

Credential Automation

Passwords and user credentials can be rotated manually or via automation tools such as HashiCorp Vault, Ansible, or CI/CD pipelines.
Automation ensures consistent rotation and reduces operational risk in production environments.

Credential Rotation Policies and Procedures

Why Rotate Credentials

Regular credential rotation reduces exposure risk and supports compliance requirements.

Password Rotation Flow

Add New Password
- Use REST API POST /v1/users/password to add a new password without immediately invalidating the old one, allowing seamless propagation.
POST https://<host>:9443/v1/users/password { "username": "alice", "new_password": "newSecureP@ssword" }

Full API examples and step-by-step instructions are in Rotate Passwords in Redis Software.
Update Clients and Systems
- Update passwords in all client applications, automation scripts, monitoring tools, and secret managers.
Remove Old Password
- Once all systems are updated, remove the old password using REST API DELETE /v1/users/password.
DELETE https://<host>:9443/v1/users/password { "username": "alice", "old_password": "oldP@ssword" }
- Note: Multiple active passwords are supported only via REST API; default users cannot rotate passwords.

Certificate Management and Rotation

Certificate Usage

TLS/SSL encryption is required for all client, inter-node, API, and replication connections.
Redis Software supports self-signed or CA-signed certificates at cluster and database levels.
Certificates must be created with the TLS Web Client Authentication attribute enabled to ensure proper validation during internode and client authentication.

Certificate Rotation Steps

REST API: Rotate cluster certificates with POST /v1/cluster/certificates/rotate. Ensure all nodes and clients trust the new certificates. Full API details are available in Rotate Cluster Certificates (REST API).
Scheduling: Configure certificate rotation jobs with cron expressions and pre-expiry triggers via the REST API. See Certificate Rotation Job Settings.

Zero-Downtime Recommendations

Rotate certificates before expiry.
Update clients before removing old certificates.
Verify cipher compatibility, formats, and expiry dates.

Customer-Managed Internode Certificates

Starting with Redis Software 8, you can replace the cluster’s self-signed internode certificates with CA-issued certificates and manage their rotation via the REST API.
This enables stronger compliance and trust chain management for node-to-node encryption, including during cluster join, node replacement, and recovery operations.

For details on required fields, configuration examples, and rotation workflow, see Customer-provided certificates in the Redis 8.0.2-17 release notes.

Troubleshooting Common Issues

Symptom	Possible Cause	Recommended Actions
Connections fail after password rotation	Clients still using old credentials	Update all clients, scripts, and secret managers
API 400/403 errors during rotation	Incomplete node updates or unsupported flow	Verify cluster health, ensure correct API usage
TLS handshake failure	Expired or mismatched certificate	Update clients with new certificates; verify CA trust and cipher compatibility
Open connections after rotation	Old connections not re-authenticated	Restart clients as necessary; Redis 7.8+ enforces disconnects on invalidated credentials

For additional guidance on troubleshooting connection issues, refer to the Redis Software Troubleshooting Guide

Password Expiration Policy (90-Day Rotation) and Recovery

Note: This is a common organizational policy and is not specific to Redis Software.

Password Expiration and Account Access Issues

If your cluster credentials suddenly stop working on a development cluster, the most common cause is a password expiration policy. Many clusters are configured to require password changes every 90 days. When the password expires, new logins fail until you reset it.

How to confirm it’s a password expiration issue

You see messages such as “password expired,” “expired credentials,” or repeated authentication failures despite using the same username.
Multiple team members with the same account experience failures at the same time.
The cluster or organization's security policy states a 90‑day password rotation requirement.

Regain access

Try a self‑service reset:
- Use the “Forgot password” or password reset option on your cluster’s sign‑in page, if available.
- If your organization uses Single Sign‑On (SSO), reset your password through your identity provider (for example, your company's account portal). SSO‑managed passwords follow your organization’s policy and may also enforce periodic changes.
Contact an admin if self‑service isn’t available:
- Reach out to your cluster or organization's administrator and request a password reset or account unlock.
- If you’re an admin, use your admin console or management tools to reset the user’s password and, if needed, unlock the account. Ensure the new password meets your organization’s complexity requirements.
Verify access after the reset:
- Sign in to the cluster with the new password.
- Confirm connectivity from the tools and clients you use (for example, CLI tools, database clients, or scripts).

Important notes

Expiration blocks new sessions; any already‑authenticated sessions may continue only until they require reauthentication or their tokens expire.
Password expiration typically doesn't automatically rotate API keys, service tokens, or service accounts unless your organization has specifically configured it that way. Verify any token policies with your admin.

Update stored credentials

Replace saved passwords in local keychains, configuration files, environment variables, and CI/CD systems.
Update secrets in secret managers or vaults used by automation.
Re‑run or restart jobs that failed due to authentication errors.

Prevent future lockouts

Set a reminder to change your password before the 90‑day mark (for example, 85 days after your last change).
Ask your admin if automated email reminders for upcoming expiration can be enabled.
Where appropriate, use SSO so your password lifecycle is managed by your corporate identity provider.
Use service accounts or tokens (with their own rotation schedules) for non‑interactive automation, per your organization’s security policy.

If you still can’t sign in

Provide your admin or support team with:

Cluster name/ID and environment (for example, dev)
Your username
Exact error message(s)
When the credentials last worked
Any recent password changes or lockout notices

About the 90‑day policy

Many clusters are configured to enforce a 90‑day password expiration to meet organizational or compliance requirements.
Only organization or cluster administrators can review or change this setting. If the current policy isn’t suitable for your workflow, discuss adjustments (for example, notification cadence, grace periods) with your admin while balancing security requirements.

Best Practices

Centralize credentials in secret managers, avoid embedding them in code.
Rotate passwords regularly and automate whenever possible.
Audit user access and enable logging for login/role changes.
Use TLS for all connections, including cluster communication and database endpoints.
Schedule certificate rotations before expiry and update clients before removing old certificates.
Avoid using the default user in production; enable RBAC and granular ACLs.
Maintain scripts and automation with current credentials and certificates.
Track credential and certificate versions and expiration dates to enforce rotation discipline.

Related to