Why Is My ACM Certificate Not Trusted? A Deep Dive into Trust Stores and Verification
Deploying an SSL/TLS certificate with AWS Certificate Manager (ACM) is often a smooth process. It integrates seamlessly with services like Elastic Load Balancing and CloudFront, providing secure connections for your users. However, you may encounter a frustrating scenario: ACM shows your certificate is valid, yet clients—browsers, applications, or APIs—are throwing trust errors and refusing to connect.
This common issue is rarely a problem with the ACM certificate itself. Instead, it almost always points to a breakdown in the SSL/TLS chain of trust, specifically related to the client’s trust store. Understanding this relationship is key to diagnosing and resolving these persistent verification failures.
This guide will walk you through the fundamentals of certificate chains, the role of trust stores, and how to ensure your clients can successfully verify your ACM-issued certificates every time.
Understanding the SSL/TLS Chain of Trust
To trust a certificate, a client doesn’t just look at the certificate itself. It verifies the entire lineage of that certificate, known as the chain of trust. This chain typically consists of three parts:
- Root Certificate: This is a top-level certificate from a highly trusted Certificate Authority (CA), like Amazon. Root certificates are pre-installed in the operating systems and browsers of most devices. They are self-signed and form the anchor of trust.
- Intermediate Certificate: To avoid issuing every certificate directly from the highly-guarded root, CAs use intermediate certificates. The root CA signs the intermediate CA, which in turn signs your server certificate. This creates a secure “chain” of authority.
- Server Certificate (End-Entity): This is the certificate issued by ACM specifically for your domain. It is trusted only because it was signed by a trusted intermediate certificate.
For a connection to be successful, a client must be able to cryptographically link your server certificate all the way back to a root certificate it already has in its local trust store. If any link in that chain is missing or untrusted by the client, the entire validation process fails.
The Role of a Trust Store
A trust store is a collection of approved CA certificates stored by a client operating system or application. Think of it as a digital address book of trusted authorities. When your server presents its certificate, the client checks its trust store to see if it recognizes the authority (the intermediate and root CAs) that signed it.
Common examples of trust stores include:
- Operating Systems: Windows Certificate Manager, macOS Keychain Access, and the
/etc/ssl/certs/directory on Linux distributions. - Web Browsers: Firefox maintains its own trust store, while Chrome and Safari typically rely on the underlying OS trust store.
- Application Runtimes: The Java KeyStore (JKS) is a well-known example. Java applications, by default, only trust the CAs included in their specific JKS file, not the OS-level store.
The problem arises when a client’s trust store is outdated or minimal. It might not contain the specific Amazon intermediate certificate that signed your ACM certificate, even if it has the Amazon Root CA. This is especially common in older operating systems, custom applications, or stripped-down container environments.
How to Diagnose and Verify Certificate Trust Issues
Before you can fix the problem, you need to confirm that a broken trust chain is the cause. Here are a few effective methods for diagnosing verification failures.
1. Use an Online SSL Checker
Tools like the SSL Labs SSL Server Test are invaluable. When you enter your domain, these tools analyze your server’s configuration and display the full certificate chain it is serving. They will explicitly tell you if the chain is incomplete or if there are any trust issues with common platforms.
2. Leverage Command-Line Tools
The openssl command is a powerful utility for direct inspection. Run the following command, replacing your-domain.com with your actual domain:
openssl s_client -connect your-domain.com:443
At the end of the output, look for the Verify return code.
Verify return code: 0 (ok)means the chain was successfully verified using your local machine’s trust store.- Any other code, such as
Verify return code: 21 (unable to verify the first certificate), indicates a trust failure. This strongly suggests your local machine is missing the necessary intermediate CA.
How to Fix ACM Certificate Trust Failures
The solution involves ensuring the client has the necessary Amazon Root and Intermediate CA certificates in its trust store.
For Web Browsers and Standard Systems
For most end-users on modern operating systems, this is rarely an issue. Windows, macOS, Android, and iOS receive regular updates that keep their trust stores current with major CAs, including Amazon Trust Services. If a user on an up-to-date system reports an issue, it’s more likely a local configuration problem on their end.
For Custom Applications and Servers
This is where manual intervention is often required, particularly for server-to-server communication or with applications built in Java, Python, or Go.
- Identify the Missing Certificate: First, determine which Amazon CA issued your certificate. You can find this by inspecting your certificate in a browser or using the
opensslcommand. - Download the Correct CA Bundle: Crucially, only download CA certificates from the official source. Amazon provides all of its root and intermediate certificates at the Amazon Trust Services Repository. Do not download them from unverified third-party websites.
- Update the Client’s Trust Store: The final step is to add the downloaded CA certificate(s) to the client’s specific trust store.
- For Java Applications: You will need to use the
keytoolutility to import the CA certificate into the application’s designated Java KeyStore (JKS) file. - For Linux Servers: You may need to add the CA certificate file to a specific directory (like
/usr/local/share/ca-certificates/) and run a command likeupdate-ca-certificates. - For Custom Code (Python/Go): Your application’s HTTP client library likely has a way to specify a custom CA bundle file for verifying connections.
- For Java Applications: You will need to use the
Security Tip: When building services, bundle the necessary intermediate CAs with your application’s trust store rather than relying on the host OS. This makes your application self-contained and resilient to variations in deployment environments, ensuring your connections are always trusted and secure. By taking these steps, you can move past frustrating trust errors and build robust, reliable systems.
Source: https://aws.amazon.com/blogs/security/how-to-configure-and-verify-acm-certificates-with-trust-stores/
