VANDEKERCKHOVE

A journey of ideas, insights, and inspiration.

End-to-End HTTPS for Kubernetes: Overcoming Let’s Encrypt Validation Issues

When configuring a secure web application on Kubernetes, ensuring end-to-end encryption is often a critical requirement. This means the traffic is encrypted from the client all the way to the backend services, without terminating SSL at an intermediary like CloudFront. However, this setup can introduce challenges when using Let’s Encrypt to manage certificates.

The Challenge: ACME HTTP Validation Behind CloudFront

Let’s Encrypt uses the ACME HTTP challenge to validate ownership of your domain. This involves serving a validation file under the /.well-known/acme-challenge/ path over HTTP. But when you configure CloudFront with redirect-to-https, all HTTP traffic is redirected to HTTPS. This breaks the ACME HTTP challenge because Let’s Encrypt expects the response over HTTP.

Allowing all HTTP traffic as a workaround would compromise your HTTPS enforcement, which isn’t ideal. A more secure approach involves creating an exception for the ACME challenge path while enforcing HTTPS for the rest of the application.

The Solution: Path-Based Exceptions in CloudFront

You can configure CloudFront to allow HTTP access specifically for the /.well-known/acme-challenge/ path, while maintaining HTTPS redirection for all other traffic. Below is a Terraform configuration that demonstrates how to achieve this.

Explanation

  1. Default Cache Behavior:
    • Enforces HTTPS (viewer_protocol_policy = "redirect-to-https") for all traffic except paths explicitly overridden by ordered_cache_behavior.
  2. Ordered Cache Behavior:
    • Matches requests to /.well-known/acme-challenge/* and allows both HTTP and HTTPS (viewer_protocol_policy = "allow-all").
    • Uses specific cache and origin request policies for minimal caching and forwarding.
  3. Custom Policies:
    • Cache policy (aws_cloudfront_cache_policy.acme) ensures minimal caching for ACME challenges.
    • Origin request policy (aws_cloudfront_origin_request_policy.acme) forwards only essential headers to the origin.
  4. Security:
    • All other paths remain fully HTTPS-enforced, preserving end-to-end encryption.
    • The ACME challenge path is narrowly scoped to minimize potential abuse.

Conclusion

By leveraging CloudFront’s path-based cache behaviors and Terraform, you can enable Let’s Encrypt to perform HTTP validation without compromising HTTPS enforcement. This approach keeps your application secure while meeting the requirements for certificate management.

Feel free to adapt the Terraform configuration to suit your specific environment. If you have additional considerations, like stricter geo-restrictions or advanced cache policies, you can layer those on top of this foundation.

Sources

https://github.com/odileon-net/examples/blob/main/terraform/aws/cloudfront/acme-challenge-example.tf

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudfront_distribution

Leave a Reply

Your email address will not be published. Required fields are marked *

Follow me for more content
Share this post if you liked it !
Comments