---
title: "ACME Certificate Validation: tls-alpn-01 vs. DNS Challenges"
description: "ACME uses different domain-control validation methods. tls-alpn-01 works on shared hosting without DNS access; DNS challenges suit wildcard certificates but require external DNS control."
---

# ACME Certificate Validation: tls-alpn-01 vs. DNS Challenges

**Type:** [Comparison](https://yomu.fyi/visual-explainers/category/comparison.md)

![Side-by-side comparison of tls-alpn-01 and DNS challenge methods for ACME domain validation, showing flow, requirements, and use cases.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/22ba8d9c-7187-4134-93c8-eb962d8856da/image-27cc94b4-24c3-45dc-a76d-0ae7bb321995.webp)

> ACME uses different domain-control validation methods. tls-alpn-01 works on shared hosting without DNS access; DNS challenges suit wildcard certificates but require external DNS control.

## Explanation

ACME (Automated Certificate Management Environment) is the protocol that lets services automatically request and renew TLS certificates from a Certificate Authority like Let's Encrypt. The protocol authenticates your account with a cryptographic key, creates an order for your domain, and then proves you control that domain through a challenge. Different challenge methods suit different hosting models: tls-alpn-01 uses ALPN during the TLS handshake and works well on shared infrastructure where you control the edge proxy but not DNS; DNS challenges require you to add a temporary record to your domain's DNS zone and work for wildcard certificates but demand external DNS access. Understanding which method fits your architecture helps you automate certificate renewal safely without exposing credentials or requiring manual intervention.

**Tags:** [ACME](https://yomu.fyi/topic/acme.md), [Architecture](https://yomu.fyi/topic/architecture.md), [Authentication](https://yomu.fyi/topic/authentication.md), [Security](https://yomu.fyi/topic/security.md), [StarRocks](https://yomu.fyi/topic/starrocks.md), [TLS](https://yomu.fyi/topic/tls.md)

## Related reading

### [The economics of agent scale: tokens, ROI, and building platforms for AI-first teams (Part 2)](https://yomu.fyi/post/the-economics-of-agent-scale-tokens-roi-and-building-platforms-for-ai.md)
- Company: [Stack Overflow](https://yomu.fyi/company/stack-overflow.md)
- Author: Eira May
- Published: Sep 3, 2026
- Type: Explainer

The conversation examines the economics and platform implications of operating dozens or hundreds of AI agents rather than a small number of human-driven workflows. Andi Gutmans argues that many current models are already sufficient for automation, shifting the optimization problem to the complete system: model, harness, context, personalization, and evaluation. The goal is the least sophisticated model and smallest viable context that produce a reliable outcome at the lowest cost, with better trajectories reducing reasoning loops and token processing; Google’s stated approach is to hill climb models and data together. The discussion also addresses cost governance, search and observability for agents as a distinct persona, human-in-the-loop handling, and the continuing importance of computer-science fundamentals, agentic fluency, and business judgment.


### [Extend Layer 2 networks into Red Hat OpenShift Virtualization with BGP and EVPN](https://yomu.fyi/post/extend-layer-2-networks-into-red-hat-openshift-virtualization-with-bgp.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Miguel Duarte de Mora Barroso, Valentino Uberti
- Published: Sep 3, 2026
- Type: Tutorial

The article describes how to extend Layer 2 networks from a legacy data-center fabric into Red Hat OpenShift Virtualization using BGP and EVPN. It uses a three-node OpenShift lab with secondary NICs on a provider network, static IPv4 addressing, a VTEP CR for 172.19.0.0/24, FRRouting peering, and a Layer 2 primary CUDN with VNI 100. The configuration preserves imported VMs’ IP and MAC identities while maintaining isolation for tenant networks that may have overlapping address spaces. In the example, an external FRR router learns the VM MAC through EVPN and reaches 22.100.0.3; after the VM moves from node 3 to node 1, the MAC remains unchanged and the advertised VTEP changes from 172.19.0.102 to 172.19.0.100. The stated result is phased migration with Layer 2 adjacency to legacy application tiers and end-to-end tenant segmentation.


### [Shared Nothing Architecture](https://yomu.fyi/post/shared-nothing-architecture.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Sep 2, 2026
- Type: Explainer

Shared-nothing architecture is presented as a scaling model for Showcase, a Ruby on Rails ballroom-competition application that began on a Mac Mini and grew to cloud VMs serving events in multiple regions. Because each event has few geographically concentrated users, a roughly one-megabyte SQLite database, about one transaction per second, and typical response times of 100ms or less, the design keeps state separate rather than sharing databases and Redis across events. The implementation runs an event’s services on one Fly.io VM, repeats that unit across machines or regions, and can place multiple event instances on one server with Phusion Passenger, NGINX, volumes, and a shared Action Cable process. It specifies 1GB machines with 2G swap after observing about 220MB idle and 450MB active RAM, and recommends WireGuard; the conclusion is that local state and fewer network calls suit this workload and can improve throughput and reliability.


### [How CDNs Generate Certificates](https://yomu.fyi/post/how-cdns-generate-certificates.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Jun 25, 2020
- Type: Explainer

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.