Cloudflare DNS + letsencrypt workflow

Our workflow is as follows:

A user hits our public domain. They actually hit AWS route53 and that brings them to our Cloudflare DNS proxy. From Cloudflare DNS we go back to AWS and they hit an AWS NLB. The load balancer is 80/443 TCP passthrough, but after that they hit a kubernetes pod with a letsencrypt cert attached to it. My question is specifically about a public user’s browser going through cloudflare (and thus the browser is returned the cloudflare cert) and then through the AWS NLB and then hitting the pod with the letsencrypt cert attached. Here’s what I don’t understand:

Firstly: is cloudflare decrypting the first, original connection, from AWS? And then encrypting it again and THEN initiating a NEW connection to our NLB and then hitting this pod? What’s happening there?

Secondly: how is the cloudflare vs letsencrypt scenario negotiated? In other words: is our letsencrypt able to decrypt this cloudflare traffic? If so, how? Is it because cloudflare and letsencrypt trust each other via cert bundles or what is going on there?


If you enable proxy :orange: on Cloudflare DNS then yes Cloudflare will need to decrypt the traffic using the private key managed by Cloudflare - to inspect the HTTP traffic so that it can be evaluated by Cloudflare security services (e.g. WAF).

When Cloudflare wants to communicate with your pod, a new SSL negotiation process takes place. During this process, your pod will send its public key (certificate) to Cloudflare, so Cloudflare will encrypt the traffic using the public key and then your pod will be able to decrypt the traffic using its private key.

@erictung that’s what I thought. In the end it was just a lack of understanding on my part of how asymmetric and symmetric encryption works! As well as some TCP confusion in there. Anyway: thanks for the prompt response.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.