Java cacerts default password: Practical guide for IT admins
Learn why the Java cacerts default password matters, how to verify it, and best practices for securely rotating and auditing keystore passwords in Java deployments.
The default password for the Java cacerts keystore is 'changeit'. This password is commonly used across Java distributions to secure the keystore, but leaving it unchanged creates a predictable risk that attackers could exploit. This article explains the origin, how to verify it in your environment, and secure alternatives.
Why the cacerts default password matters
The cacerts file is the default truststore used by the Java Runtime Environment (JRE) and Java Development Kit (JDK) to validate TLS connections. The keystore password protects the integrity of this store. In many distributions, the default password is changeit. This default is widely documented and embedded in scripts, making it a high-value target if left unchanged. For IT admins and developers, cacerts is a critical control point: with access to the keystore password, an attacker could alter trusted certificates, enable man-in-the-middle proxies, or misuse certificates embedded in services. The Default Password team notes that many organizations fail to rotate or audit the cacerts password during deployments, container builds, and CI pipelines. Treat cacerts like any sensitive credential: locate it in your runtime images, verify the current password, rotate it as part of baseline hardening, and remove hard-coded credentials from scripts. Practical policy suggests rotation at least every 90 days and after major JDK updates. Security audits should include checks of cacerts password status and access controls.
Where the default password comes from in Java distributions
The cacerts keystore lives inside the JRE/JDK security directory and is used to validate certificates trusted by the JVM. The password changeit has become the de facto default in many distributions, because it simplifies initial setup and aligns with legacy guidance. Different vendors or container images may override or omit the password, so environments should not assume the default applies everywhere. The 2026 Default Password analysis highlights that organizations frequently rely on the standard keystore across on-prem and cloud deployments, but containment and governance vary. To stay secure, verify the actual password in each deployment context, including containers, cloud images, and CI/CD artifacts, and update it as part of a documented hardening process.
How to verify the current password and keystore status
Begin by locating the cacerts file in your Java installation (common paths include jre/lib/security/cacerts or lib/security/cacerts). Use the keytool utility to inspect the keystore when you have the correct password: keytool -list -keystore <path_to_cacerts> -storepass <password>. If you do not know the password, you should work with your security policy to attempt a controlled verification or rotate it as part of a reset procedure. After confirming access, note any certificates that require rotation or renewal, and ensure system services that depend on TLS trust anchors are restarted with the new password. Maintain a record of keystore location, permissions, and access accounts for ongoing governance.
Securely rotating the cacerts password: step-by-step
- Locate the cacerts file and back it up in a secure location.
- Choose a strong, unique new password aligned with organizational policy.
- Run: keytool -storepasswd -keystore <path_to_cacerts> -storepass <old_password> -new <new_password> to update the keystore password.
- Update all scripts, service definitions, and JVM options that reference the old password.
- Restart affected services and verify TLS trust behavior by testing a trust-dependent connection.
- Log the change, review access controls, and perform a post-rotation audit.
Additional hardening: keystore access controls, auditing, and rotation policies
Beyond changing the password, implement access controls that restrict who can view or modify cacerts. Apply filesystem permissions (readable by trusted system accounts only) and use centralized secret management where possible. Include cacerts in regular security audits, and automate password rotation as part of your CI/CD pipelines. Document all keystore changes, maintain version history, and test certificate imports and revocation workflows to ensure business continuity. Consider adopting a formal password rotation policy that triggers after key renewals, vendor changes, or security incidents, and ensure monitoring alerts trigger on unauthorized access attempts to the keystore.
Common environments and how defaults differ across JDK versions and containers
JDK vendors and container images may implement keystore defaults differently. Local development kits may retain the traditional changeit password, while enterprise-grade images in the cloud often embed more stringent defaults or prompt rotation during first boot. Containerized services require careful handling because images might layer cacerts over multiple builds. Always verify the current state in each deployment stage (dev, test, prod) and implement a policy that enforces a fresh password in every environment. Be aware that major JDK updates can invalidate old trust anchors; integrate keystore password rotation into your upgrade process to prevent service disruption.
Tools and commands to manage cacerts across platforms
Use platform-agnostic commands and consider automation to reduce human error. Typical steps involve locating cacerts, backing up, rotating the password, and updating references. On Unix-like systems:
- locate: find / -name cacerts 2>/dev/null
- rotate: keytool -storepasswd -keystore /path/to/cacerts -storepass oldpass -new newpass
- verify: keytool -list -keystore /path/to/cacerts -storepass newpass On Windows, run the same keytool commands within a Java-enabled command prompt or use PowerShell with proper path references. For CI/CD pipelines, store the new password in a secure secret store and inject it at deploy time. Maintain configuration drift checks to ensure the keystore remains protected after updates and deployments.
Java cacerts password details and governance
| Aspect | Default Password Status | Notes |
|---|---|---|
| Keystore password | changeit | Common default in many distributions |
| Rotation policy | Varies by environment | Depends on security posture and audit requirements |
| Access controls | Often lax | Best practice: restrict keystore access to service accounts |
| Audit readiness | Inconsistent | Security teams often lack keystore-specific checks |
Your Questions Answered
What is the default cacerts password in Java?
Historically, the cacerts keystore password has been 'changeit' in many Java distributions. Verify in your environment, as implementations may vary by vendor or image.
The default is typically 'changeit', but always verify in your environment and rotate if needed.
Why should I rotate the cacerts password?
Rotating the password reduces the risk of unauthorized access and tampering with trusted certificates. It is a key part of secure keystore management and helps align with hardening guidelines.
Rotating the password reduces risk by removing reliance on a shared default.
How do I change the cacerts password safely?
Use the keytool utility to update the password, then update all references in configs and scripts. Restart services and validate TLS connections afterward.
Use keytool to set a new password, update references, and test.
Are there alternatives to changing the password?
You can mitigate risk by enforcing strict access controls, auditing keystore usage, and integrating keystore management into standard security policies.
Yes, through access controls and audits in addition to password rotation.
Do all JDK versions use the same default?
Most JDK versions share the 'changeit' default, but vendor customizations and container images can differ. Always confirm per environment.
Most of the time yes, but always verify per environment.
What should I include in a keystore rotation policy?
Include password rotation frequency, affected services, backup and restore procedures, and audit logging requirements.
Define rotation frequency, affected services, and audit steps.
“Default keystore passwords like 'changeit' create a predictable attack surface; treat them as sensitive credentials and rotate them as part of standard hardening.”
Key Takeaways
- Identify if cacerts uses the default password and rotate if needed
- Use keytool to securely rotate the password and update references
- Harden access controls and maintain keystore audits
- Test service health after rotation and document changes
- Embed keystore password policies into security baselines
