SSL handshake issue from lambda

Hello.

The error SSLHandshakeException: (certificate_unknown) No subject alternative DNS name matching found indicates that the SAN (Subject Alternative Name) of the certificate returned by the destination does not include the hostname used by the client. Since test Lambdas within the same VPC can connect, but the target Lambda fails, it is highly likely that the cause is a difference in the communication path or the destination hostname.
Is the Lambda function that experienced the error able to connect to the VPC successfully?
Also, do the connection destination specified in your Lambda code and the DNS name of the connection destination match?

That error is hostname verification failing, not a trust problem. The JVM validated the chain fine, then rejected the cert because none of its SANs matched the name the client connected to. If the CA were the issue you'd get unable to find valid certification path to requested target instead.

"Same VPC, same destination" doesn't rule this out, because three things vary independently between two functions: the hostname string actually handed to the HTTP client, whether SNI gets sent, and therefore which certificate the server returns. A server hosting multiple names returns its default cert when SNI is absent, so two functions calling the identical endpoint can legitimately be shown different certs.

Instead of diffing the two code paths by eye, get the handshake to tell you. Add this env var to both functions and invoke each once:

JAVA_TOOL_OPTIONS = -Djavax.net.debug=ssl:handshake

Lambda supports JAVA_TOOL_OPTIONS on the Java runtimes. In the CloudWatch logs, check two things:

• the ClientHello — is there a server_name extension, and what's its value? If it's absent, SNI isn't being sent.
• the returned leaf cert — what are its SANs?

That distinguishes "wrong hostname" from "no SNI" from "server returned an unexpected cert" in one shot. Remove the var afterwards, it's very noisy.

On the likely cause: your trace shows java.util.concurrent.ExecutionException, so the failing call is going through an async client (Netty, CRT, or something wrapped in a CompletableFuture). That's very often a different HTTP stack than a quick test function using HttpsURLConnection or a sync SDK client, so compare the client library and version before comparing anything else. SNI also gets silently dropped when you connect to a literal IP and carry the name only in a Host header, or when you build a raw SSLSocket without calling setServerNames.

Other things that produce exactly this message:

• A VPC interface endpoint DNS name used directly. If private DNS is off and the code targets vpce-<endpoint-id>.<service>.<region>.vpce.amazonaws.com, that name isn't in the service cert's SAN list. Fix by enabling private DNS on the endpoint and calling the normal regional endpoint.
• A TLS-intercepting proxy on one function only. Check whether HTTP_PROXY / HTTPS_PROXY / NO_PROXY are set on the failing function but not the working one.
• The shape of the hostname. An S3 bucket name with dots in it breaks the wildcard cert (the wildcard matches only buckets without dots). A trailing dot (host.example.com.) or an underscore will also fail SAN matching.

One more thing worth checking: the JDK normally formats this as No subject alternative DNS name matching <host> found. In your paste there's nothing between "matching" and "found". If that's verbatim and not redacted, the client had no hostname to verify against at all, which points straight at connecting by IP.

Whatever you find, don't work around it with a permissive HostnameVerifier or a trust-all TrustManager — that switches off the check that just caught this. If the endpoint really does serve a name that isn't in its SAN list, reissue the cert with the correct SAN.

A few things worth checking here, because SSL handshake failures from a VPC-connected Lambda can come from two different places and they look identical in the error.

The first is certificate trust. Lambda's execution environment ships its own CA bundle, and if the endpoint uses a private CA or an intermediate chain that isn't in that bundle, the handshake fails even though the cert is technically valid. The fix there is to bundle the correct CA cert (or the full chain) into your deployment package and point your HTTP client at it explicitly.

The second, and the one that trips people up in VPC specifically, is DNS resolution. When Lambda is in a VPC, it resolves names through the VPC resolver. If the hostname resolves to a different IP than expected, or if you're hitting a private endpoint that presents a cert with a different CN/SAN than the hostname you called, you get a mismatch that looks like a cert problem but is really a routing problem. Worth running a quick check: does the hostname your code calls match exactly what's in the cert's Subject Alternative Names?

Refer article that walks through both the cert verification path and the network config side for this exact scenario: https://repost.aws/knowledge-center/lambda-https-ssl-certificate

I do AWS architecture and troubleshooting advisory work, so if you can share the exact error string and whether you're hitting an AWS service endpoint or a third-party one, I can take a closer look and give you a more specific pointer.