Secure internal TLS with ACME proxies and DNS delegation

Self-hosted environments often struggle to obtain valid TLS certificates for services that are not directly accessible from the internet. A recent technical guide by Sapiolab outlines a robust architecture using an ACME proxy and a dedicated DNS server to solve this connectivity gap. Published on October 15, 2026, the article provides a step-by-step method for homelab operators and small IT teams to automate certificate issuance securely.

What happened

The core challenge addressed is the limitation of standard ACME validation methods for internal servers. HTTP-01 challenges require the server to be reachable from the public internet, which is often impossible or unsafe for private infrastructure. DNS-01 challenges require API access to the authoritative DNS provider, which poses security risks if credentials are exposed on internal machines. The proposed solution involves deploying an ACME proxy that acts as an intermediary between internal clients and public Certificate Authorities.

This proxy converts internal validation requests into external DNS-01 orders. To avoid exposing primary DNS API keys, the setup utilizes a separate ACME DNS server. This local server handles challenge records via a CNAME delegation trick, allowing public CAs to validate domain ownership without accessing the main DNS zone. The guide walks through installing MariaDB, NGINX, Step CA, and Unbound to create a fully automated, secure certificate pipeline.

Key details

• The architecture uses Step CA or Lab-CA for internal certificate management, with Step CA noted for being lighter and simpler to install.
• An ACME proxy translates internal HTTP-01 or DNS-01 requests into external DNS-01 orders for public CAs like Let’s Encrypt or ZeroSSL.
• External Account Binding (EAB) can group multiple internal accounts under one external account, though domain verification behavior may vary by provider.
• ACME DNS serves as a bridge, hosting _acme-challenge TXT records locally while the public CA follows a CNAME record to find them.
• The setup requires a split-DNS configuration using Unbound to resolve internal queries correctly while delegating challenge subdomains.
• Private certificates avoid Certificate Transparency logs but require manual trust store installation on every client device and container image.

Background

ACME is the protocol used by most modern Certificate Authorities to automate the issuance of TLS certificates. It relies on challenges to prove domain ownership. HTTP-01 places a file on the web server, while DNS-01 adds a specific text record to the domain's DNS zone. For internal servers, neither method is straightforward because the server is hidden behind firewalls, and granting DNS API access to every internal service creates a significant security surface area.

Certificate Transparency logs are public ledgers that record all issued public certificates. While this enhances overall internet security, it also allows attackers to discover new subdomains and services. Private Certificate Authorities avoid these logs but introduce operational overhead, as every device and application must be configured to trust the private root certificate. This is particularly difficult in heterogeneous environments using Docker containers or languages like Python that maintain their own certificate stores.

Why it matters

For teams running self-hosted software, maintaining valid TLS certificates is critical for security and compliance. Expired or invalid certificates break integrations, cause browser warnings, and erode user trust. Automating this process reduces the administrative burden on DevOps engineers who otherwise might rely on manual renewal scripts or long-lived static certificates. The ACME proxy pattern allows organizations to use trusted public certificates for internal services without compromising network security by opening inbound ports.

Furthermore, separating the DNS validation mechanism from the primary DNS provider limits the blast radius of a potential credential leak. If an internal service is compromised, the attacker only gains access to the limited ACME DNS server, not the ability to modify critical DNS records like MX or A records for the main domain. This defense-in-depth approach is essential for small and mid-sized companies that manage their own infrastructure but lack large security teams.

What you can do

• Evaluate whether your internal services can tolerate the operational overhead of managing a private CA trust store across all clients.
• Deploy an ACME proxy such as the one described with Step CA to handle certificate requests from internal networks.
• Set up a dedicated ACME DNS instance to handle challenge records, avoiding the need to expose primary DNS API keys.
• Configure CNAME records in your public DNS zone to delegate _acme-challenge subdomains to your local ACME DNS server.
• Implement split-horizon DNS using tools like Unbound to ensure internal clients resolve services correctly while external validators can reach the challenge records.
• Monitor certificate expiry dates actively, as automated systems can still fail due to network changes or configuration drifts.