---
title: "How CDNs Generate Certificates"
description: "Fly describes how its CDN automatically generates TLS certificates for customer hostnames with Let’s Encrypt and ACME, focusing on why the older tls-sni-01 validation method was unsafe on shared hosting. ACME authenticates an account with an ECDSA/EdDSA key, creates an order, and verifies domain control through challenges; Fly uses tls-alpn-01, which avoids requiring DNS access or port 80. For validation, Fly requests a challenge, creates a self-signed certificate containing Let’s Encrypt’s token, stores it in distributed certificate storage, and signals the CA to connect with a ClientHello selecting acme-tls/1 via ALPN. The Rust proxy recognizes that ALPN case, retrieves the challenge certificate, and serves it to Let’s Encrypt, which completes the challenge and permits certificate issuance. Fly assigns each application a unique routable IPv6 address and requires CNAME resolution to it for ALPN validation; wildcard certificates instead use DNS challenges."
---

# How CDNs Generate Certificates

[Fly.io](https://yomu.fyi/company/fly-io) · Jun 25, 2020

**Type:** Explainer

## Summary

Fly describes how its CDN automatically generates TLS certificates for customer hostnames with Let’s Encrypt and ACME, focusing on why the older tls-sni-01 validation method was unsafe on shared hosting. ACME authenticates an account with an ECDSA/EdDSA key, creates an order, and verifies domain control through challenges; Fly uses tls-alpn-01, which avoids requiring DNS access or port 80. For validation, Fly requests a challenge, creates a self-signed certificate containing Let’s Encrypt’s token, stores it in distributed certificate storage, and signals the CA to connect with a ClientHello selecting acme-tls/1 via ALPN. The Rust proxy recognizes that ALPN case, retrieves the challenge certificate, and serves it to Let’s Encrypt, which completes the challenge and permits certificate issuance. Fly assigns each application a unique routable IPv6 address and requires CNAME resolution to it for ALPN validation; wildcard certificates instead use DNS challenges.

## Context

Fly needs to generate certificates automatically for applications and customer domains. The post also explains that tls-sni-01 became unsafe because shared hosting providers could let users claim arbitrary names and upload certificates, enabling validation attacks against other hosted customers.

## Approach / What changed

Fly uses Let’s Encrypt’s ACME tls-alpn-01 challenge. It embeds the issued token in a self-signed certificate, stores that certificate in distributed storage, and has a Rust proxy serve it when Let’s Encrypt connects with the acme-tls/1 ALPN protocol. Unique routable IPv6 addresses and CNAME checks mitigate domain-validation risks; DNS challenges support wildcard certificates.

## Takeaways

- The tls-sni-01 challenge was deprecated and removed after shared-hosting configurations allowed attackers to claim .invalid names and present token-bearing certificates for other customers’ domains.
- The tls-alpn-01 flow uses a self-signed certificate containing Let’s Encrypt’s token; Fly’s proxy serves it specifically when the validation connection selects acme-tls/1 through ALPN.
- Fly requires a hostname to resolve by CNAME to an application’s unique routable IPv6 address for ALPN validation. Wildcard certificate requests use DNS challenges instead.

**Tags:** [ACME](https://yomu.fyi/topic/acme), [DNS](https://yomu.fyi/topic/dns), [Rust](https://yomu.fyi/topic/rust), [TLS](https://yomu.fyi/topic/tls)

- Source: [Fly.io](https://fly.io/blog/how-cdns-generate-certificates)
- Source URL: https://fly.io/blog/how-cdns-generate-certificates
- Ingested by Yomu: 2026-09-02T11:57:07.910Z

[Read original post](https://fly.io/blog/how-cdns-generate-certificates)