When evaluating an appliance-based solution for a self-hosted office and communications stack, technical buyers consistently prioritize two non-negotiable requirements: robust security and operational simplicity. At RemoteRails, we recognize that managing TLS certificates and DNS challenges is often the most complex aspect of deploying a self-hosted infrastructure.
To address this, the RemoteRails architecture provides two distinct, automated pathways for ACME DNS-01 challenges and certificate issuance. Whether your organization prioritizes the ‘set-and-forget’ ease of managed DNS or the strict isolation of a self-hosted DNS zone, our deployment experts configure the stack to adapt to your specific threat model and security posture.
Let’s dive into how RemoteRails handles Let’s Encrypt, ZeroSSL, Cloudflare, and acme-dns under the hood.
Future-Proofing Your Infrastructure: The End of Manual Certificates
Before looking at the architecture, it is critical to understand why automated certificate issuance is no longer optional.
The industry is actively killing off manual TLS certificate management. The CA/Browser Forum (CA/B) has been aggressively shortening the maximum allowed lifespan for public certificates. While certificates were once valid for years, today the maximum validity is hovering around 200 days. More alarmingly for IT teams, the CA/B has signaled an upcoming mandate to slash maximum certificate lifespans to just 47 days by 2029.
Manually replacing and provisioning certificates every 40 days across an entire infrastructure is simply not feasible; it is a recipe for catastrophic outages. RemoteRails was built from day one with 100% automated certificate management. By natively integrating ACME automation at the architectural level, RemoteRails ensures that all customers are completely future-proofed against these industry changes. Your certificates will renew silently and automatically, forever.
The Challenge: Why DNS-01?
RemoteRails operates heavily behind firewalls and VPNs (via Defguard) to secure your communications suite. Because many internal services are not exposed to the public internet, traditional HTTP-01 challenges for TLS certificates will fail.
To solve this, RemoteRails exclusively uses DNS-01 challenges. This challenge proves domain ownership by creating a temporary TXT record in your DNS zone, allowing Let’s Encrypt to issue wildcard certificates (*.yourdomain.com) that secure both your public-facing and internal-only endpoints.
During the provisioning phase, our RemoteRails architects work with your IT team to select the best DNS-01 provider for your environment. We primarily offer two architectural models:
Path 1: The Managed Approach (Cloudflare + Traefik)
For organizations that want a frictionless setup, this path offers unparalleled simplicity by offloading the certificate lifecycle entirely to Traefik’s built-in ACME client.
Technically, if your domain registrar lacks a programmable API, you could simply migrate your authoritative nameservers to a managed DNS provider that does support APIs (such as Cloudflare, AWS Route 53, or DigitalOcean). RemoteRails natively automates Cloudflare out-of-the-box for this exact scenario.
How it Works
- The Configuration: Our deployment technicians activate the Cloudflare-specific topology for your appliance.
- Authentication: You securely provide a scoped Cloudflare DNS API Token, which is injected into the Traefik container’s environment.
- Automated Issuance: Traefik natively orchestrates the
dns-01challenge via the Cloudflare API. It securely requests, provisions, and renews a Let’s Encrypt wildcard certificate. - Internal Storage: The resulting certificates are stored safely within Traefik’s internal
acme.jsonstorage. - Dynamic Routing: Every service within the RemoteRails stack (Nextcloud, Matrix, Vaultwarden, etc.) is automatically protected using Traefik’s dynamic routing labels.
The Verdict: This is the most streamlined approach, requiring zero manual DNS configuration after the initial token handoff. However, it requires you to entrust your authoritative DNS zone to Cloudflare, which carries significant jurisdictional implications.
The Jurisdictional Drawbacks of US-Based Managed DNS
While Cloudflare is highly convenient, it is a United States company and is entirely subject to US jurisdiction. For threat models that prioritize strict sovereignty, handing over your authoritative DNS zone to a US entity presents a massive vulnerability.
Cloudflare is legally obligated to comply with US court orders, subpoenas, and national security letters. This means that regardless of where your actual RemoteRails appliance is physically hosted, US authorities could compel Cloudflare to perform a DNS takedown—either by null-routing your domain or secretly redirecting your DNS traffic to a server controlled by law enforcement.
Many sovereignty-focused organizations deliberately use non-US operated ccTLDs (like .ch for Switzerland or .is for Iceland) to achieve jurisdictional isolation. Putting Cloudflare, AWS, or DigitalOcean in the middle of that chain completely defeats the purpose of that isolation.
Path 2: The Sovereign Approach (Self-Hosted acme-dns + acme.sh)
For organizations that refuse to compromise on jurisdictional isolation, RemoteRails recommends and configures the acme-dns path.
By using this path, you can pair your RemoteRails appliance with a privacy-focused DNS provider, such as 1984.Hosting based in Iceland, to benefit from their incredibly strong media freedom and freedom of speech legal frameworks. This architecture is vastly superior for high-security threat models because it solves the API isolation dilemma natively.
How it Works
- The Configuration: Our team deploys a specialized topology that boots three dedicated services:
acme-dns(the DNS server),acmedns-db(its Postgres database), andacme-daemon(theacme.shclient). - The CNAME Delegation: During setup, your IT team will manually create a single CNAME record at your authoritative DNS host (e.g., 1984.Hosting). This record points
_acme-challenge.yourdomain.comto the new, self-hostedacme-dnsserver running on the appliance. - Separation of Concerns: This CNAME delegation is the magic of
acme-dns. It completely separates the certificate issuance path from your authoritative DNS zone. Your appliance never holds API keys capable of modifying your root DNS records; it only manages the temporary verification record. - Certificate Authority Redundancy (ZeroSSL vs Let’s Encrypt): By default, the underlying
acme.shclient uses ZeroSSL as its Certificate Authority rather than Let’s Encrypt. ZeroSSL is a highly reputable CA owned by HID Global (a global leader in smart card and access control technologies), which is itself part of the Swedish Assa Abloy conglomerate. ZeroSSL provides automated, free, and universally trusted certificates. While RemoteRails explicitly enforces Let’s Encrypt out-of-the-box to guarantee deployment consistency, our architecture is fully capable of utilizing ZeroSSL equally well. This eliminates reliance on Let’s Encrypt as a single point of failure and allows our technicians to effortlessly switch your appliance to European CA infrastructure if required. - Dynamic File Provisioning: Traefik’s native ACME resolver is completely disabled in this topology. Instead,
acme.shinstalls the generated certificates into a secure, shared directory. Traefik is configured via a dynamic file provider to continuously watch this directory and hot-reload the certificates as they are renewed.
The Verdict: This path exemplifies the principle of least privilege and jurisdictional resilience. It allows you to use any authoritative DNS host in the world—especially those in protected jurisdictions—without needing a custom API integration for each one. It keeps your DNS zone completely out of US jurisdiction while still enjoying fully automated wildcard certificates. It is the ultimate sovereign solution.
Beyond Web Traffic: Seamless Integration with Stalwart Mail
Securing HTTPS web traffic is only half the battle; an enterprise communications stack also relies heavily on email protocols. RemoteRails optionally bundles Stalwart Mail, a modern, highly secure mail server, which integrates seamlessly into either certificate architecture.
For the Managed Path (Cloudflare): When using Traefik’s built-in ACME client for web traffic, Stalwart Mail acts as its own ACME client. It connects directly to the Cloudflare API to provision and renew its own certificates for its IMAP, JMAP, and SMTP endpoints. This is the recommended setup when you are already entrusting API access to a managed provider.
For the Sovereign Path (acme-dns): When deploying via the sovereign acme-dns path, strict API isolation is the priority. Instead of acting as an ACME client, Stalwart Mail is configured to read certificates directly from the secure volume populated by the central acme.sh container. This means your mail endpoints are served over SSL/TLS using the exact same wildcard certificate, requiring absolutely no duplicate issuance processes or API tokens within the mail server itself.
Furthermore, deploying a mail server requires managing a host of specific DNS records (e.g., SRV for service autodiscovery, MX for mail routing, and TXT records for SPF, DKIM, and DMARC). To accommodate your deployment strategy, Stalwart Mail within RemoteRails supports two methods for this:
- Automated API Management: If you opt for an API-capable provider like Cloudflare (or others natively supported by Stalwart such as AWS Route 53 or DigitalOcean), the appliance can automatically provision and manage these complex mail DNS records for you.
- Manual Sovereignty: If you are utilizing the sovereign
acme-dnspath with a provider like 1984.Hosting, our technicians provide you with the exact, one-time static records to manually configure in your authoritative zone, ensuring your mail infrastructure remains completely isolated from external API access.
Summary
When evaluating RemoteRails as your appliance-based office stack, you aren’t forced into a one-size-fits-all security model.
- Choose Cloudflare if you want a frictionless, managed DNS experience and your threat model tolerates US jurisdiction over your authoritative nameservers.
- Choose acme-dns if you require strict API isolation, want to enforce true jurisdictional isolation with a host like 1984.Hosting, or mandate a 100% sovereign infrastructure immune to foreign DNS takedowns.
Regardless of your choice, our technicians ensure that your internal and external communications are always secured by valid, automatically renewing wildcard certificates, keeping your deployment resilient against the CA/B forum’s ever-shortening lifespans.