Unable to execute HTTP request: Certificate for abc.us-east-1.amazonaws.com doesn't match any of the subject alternative names

What it means

TLS verification asks two separate questions, and the error text tells you which one failed. Is this certificate issued by someone I trust? And does it actually cover the hostname I asked for? "Doesn't match any of the subject alternative names" is the second question answered no — the chain verified, the certificate is real, and it was issued for a different name.

On Lambda the usual cause is a VPC interface endpoint without private DNS. An endpoint gets its own DNS names, and if code reaches it by one of those, it is asking for a hostname that AWS's service certificate does not list. Enabling private DNS on the endpoint makes the service's normal hostname resolve to it privately, so the code keeps asking for the name the certificate was issued for and verification passes. The fix is a single property, and it is a configuration change rather than a code one.

The other shape of TLS failure reads differently and needs a different response. "Unable to get local issuer certificate", "unable to verify the first certificate", SSLCertVerificationError — those are trust-chain problems, usually a proxy re-signing traffic or a stale CA bundle vendored into the package. Reading which of the two you have before changing anything saves solving the wrong problem.

There is one fix worth naming in order to rule it out. Disabling certificate verification makes the error stop, and it removes exactly the protection that error exists to provide — every one of these failures is TLS reporting that the connection is not verifiably going where you think. Where a corporate proxy is legitimately re-signing traffic, the answer is to trust its CA explicitly, which keeps verification on and working. verify=False is not a fix, and it tends to survive far longer in a codebase than the incident that introduced it.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

Read the hostname in the message and ask whether it is the one your code names. A regional service endpoint that your code never mentions — particularly one with an unfamiliar prefix — means the request was routed somewhere other than where the code intended, which is the VPC endpoint case.

Distinguish the two shapes. "Doesn't match any of the subject alternative names" is a name mismatch: verification worked and the certificate is for something else. "Unable to get local issuer certificate" or "unable to verify the first certificate" is a trust problem: the chain could not be validated, which is a different fix entirely.

Check whether the function is VPC-attached and whether an interface endpoint exists for the service. That combination plus this error is nearly diagnostic on its own.

Causes, most likely first

Fixes

yamlSecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref Vpc
    ServiceName: !Sub "com.amazonaws.${AWS::Region}.secretsmanager"
    VpcEndpointType: Interface
    PrivateDnsEnabled: true      # without this, the certificate will not match
    SubnetIds: !Ref PrivateSubnets
    SecurityGroupIds: [!Ref EndpointSecurityGroup]

python# Leftover from local testing — asks for a hostname no AWS cert covers.
# s3 = boto3.client("s3", endpoint_url="https://s3.internal.test")

s3 = boto3.client("s3")

bashopenssl s_client -connect secretsmanager.us-east-1.amazonaws.com:443 \
  -servername secretsmanager.us-east-1.amazonaws.com </dev/null 2>/dev/null |
openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

pythonimport boto3
# Trust the corporate CA, packaged with the function.
s3 = boto3.client("s3", verify="/var/task/certs/corporate-ca.pem")
# Never: verify=False

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Troubleshoot networking issues
• Amazon VPC User Guide — Access an AWS service using an interface VPC endpoint