The TLS Certificate Paradox: Why AWS Lambda Doesn’t Need NLB Certificates (But Fails on On-Prem TLS)

In a recent project, I deployed a Lambda function using the .NET 8 runtime that invoked an NLB HTTPS endpoint. Surprisingly, I didn’t install the NLB certificate in the .NET client code, yet everything worked fine.

Since I’m new to .NET projects but come from a Java background, this caught my attention. In Java, whenever I call an HTTPS endpoint, I usually need to create a truststore and install the server’s public certificate.

This led me to explore and understand why it worked in .NET Lambda without explicitly installing the certificate. I discovered that it has nothing to do with the .NET Lambda runtime vs Java Lambda runtime. The real answer lies in the NLB’s ACM certificate, which is issued by a trusted public Certificate Authority (CA). Since that CA is already trusted by the Lambda runtime’s operating system, the connection works without any manual certificate installation.

Below is a detailed explanation:

Why Lambda does not “need” NLB’s certificate ?

NLB uses ACM certificate issued by a public CA (Amazon Trust Services, DigiCert, Let’s Encrypt, etc). AWS Lambda’s execution environment already has the system trust store with all major public CAs. So when NLB presents its certificate, Lambda can validate it automatically, Lambda’s runtime already trusts NLB public CA certificate by default.

• 👉 No need to bundle/upload/install the NLB’s cert file in Lambda

Why Lambda “needs ” On-prem certificate

• Most on-prem TLS endpoints don’t use a public CA
• They often use an internal CA (corporate PKI) or even a self-signed cert
• AWS Lambda’s system trust store does not know about your internal CA
• So when Lambda connects, validation fails with: SSL: CERTIFICATE_VERIFY_FAILED
• 👉 That’s why you need to bundle your internal CA cert and tell Lambda (via code/env var) to trust it.

The core difference

• NLB/ACM cert = public trust → Lambda already trusts it
• On-prem cert = private/self-signed trust → Lambda does NOT trust it unless you give it the CA

Key Rule

Lambda only needs the certificate if the endpoint uses a certificate that’s not trusted by the default CA bundle

When a Lambda function makes an outbound HTTPS call to an on-prem endpoint, we must bundle the public certificate of the private or self-signed Certificate Authority (CA) that issued the on-prem server’s certificate.

This bundled file acts as a trust store, telling the Lambda function’s code:

“I explicitly trust any certificate signed by this specific authority.”

What to Bundle

We should bundle the .crt or .pem file that contains the public key of the Certificate Authority (CA) that signed the on-premise server's SSL/TLS certificate.

• If the on-prem server uses a self-signed certificate: Bundle the .crt file of the server's certificate itself
• If the on-prem server’s certificate was issued by a private CA: Bundle the public .crt file of that private CA, and any intermediate CA certificates in the chain

We then include this file in your Lambda function’s deployment package (either the .zip file or the container image).

If you found this helpful, don’t forget to give this article a clap 👏 and **follow **me for more tips and insights! Your support means a lot.