ALB Certificate Chain Break Causes curl to Report "unable to get local issuer certificate"

After configuring HTTPS on an internal ALB, clients accessing the domain receive curl: (60) SSL certificate problem: unable to get local issuer certificate. This error is not necessarily a network issue — more commonly it means the ACM certificate chain bound to the ALB is incomplete, or the certificate SAN does not cover the accessed domain.

Symptoms

Accessing an internal service results in an error:

curl https://service.example.internal/api/v1/health

curl: (60) SSL certificate problem: unable to get local issuer certificate

The architecture is roughly:

Client -> Internal ALB 443 -> Backend Target 443

If bypassing the ALB and directly accessing the backend target succeeds, it indicates the backend service itself is most likely not the root cause.

Troubleshooting Approach

1. Don't Rely on Public SSL Check Results

If the domain resolves to an internal ALB in a Route 53 private hosted zone, a public SSL checker may see a different public DNS record. Public check results cannot represent the certificate actually served by the internal ALB.

2. Use openssl to Inspect the Actual ALB Certificate

Run the following on an internal client:

openssl s_client -showcerts \
  -connect <alb-dns-name>:443 \
  -servername service.example.internal </dev/null

Focus on two things:

• Whether the certificate SAN/CN covers the accessed domain.
• Whether the intermediate certificate served by the ALB matches the site certificate's signing chain.

3. Distinguish Between Two Problems

A broken certificate chain and a domain mismatch are two different problems:

• A broken chain causes the client to fail to find a trusted parent CA.
• SAN not covering the domain causes hostname verification to fail.

Either one can cause HTTPS to fail.

Root Cause

In this case, the site certificate was issued by a DV intermediate CA, but the one included during ACM import was a different OV intermediate CA. The ALB therefore served a mismatched intermediate certificate chain to the client, and curl could not build a complete trust chain.

At the same time, the ALB-bound certificate's SAN also did not cover the actual domain being accessed. In other words, even if the certificate chain were fixed, it would still fail due to the domain mismatch.

Solution

1. Fix the ACM Certificate Chain

Re-import the original ACM certificate and upload the correct intermediate certificate chain:

aws acm import-certificate \
  --certificate-arn <certificate-arn> \
  --certificate fileb://site.crt \
  --private-key fileb://site.key \
  --certificate-chain fileb://correct-chain.crt

The advantage of using reimport is that it preserves the original ARN, so the ALB listener does not need to re-select a certificate.

2. Ensure the Certificate Covers the Accessed Domain

Check whether the certificate SAN includes the domain being used:

openssl x509 -in site.crt -noout -text | grep -A1 "Subject Alternative Name"

If it does not, you need to request or import a new certificate that covers the target domain and bind it to the ALB HTTPS listener.

3. Clean Up ALB Listener Certificates

If the ALB has multiple certificates attached, it is recommended to clean up unused certificates to avoid SNI matching confusion and operational judgment errors.

Summary

When ALB HTTPS reports unable to get local issuer certificate, the troubleshooting focus should be the certificate chain actually served by the ALB, not the backend Nginx or public SSL check results.

Recommended fixed troubleshooting order:

1. Use openssl s_client -showcerts on an internal client to inspect the certificate served by the ALB.
2. Check whether SAN/CN covers the accessed domain.
3. Check whether the intermediate certificate matches the site certificate's signing chain.
4. Use ACM reimport to fix the certificate chain, and replace the listener certificate if necessary.