If you run FileMaker Server on an internal network, you’ve probably hit the SSL wall.

Modern FileMaker workflows demand a valid, publicly trusted TLS certificate: the Data API, OData, WebDirect, and encrypted client connections on port 5003 all rely on it. Even fetch() calls inside Web Viewers will silently fail if your certificate isn’t trusted by the OS.

Why the built-in Let’s Encrypt button fails #

FileMaker Server includes a convenient “Request Let’s Encrypt Certificate” button in the Admin Console. Unfortunately, it relies on Let’s Encrypt’s HTTP-01 challenge, which requires Let’s Encrypt to reach your server from the public internet on port 80.

If your FileMaker Server sits on a private LAN IP, or if ports 80 and 443 on your router are already reserved for another web server, HTTP-01 can never succeed. Clicking that button will only time out and burn through Let’s Encrypt’s validation rate limits.

The solution: DNS-01 validation #

Instead of proving domain ownership over HTTP, Let’s Encrypt’s DNS-01 challenge verifies a temporary _acme-challenge TXT record in your domain’s DNS zone.

Because Let’s Encrypt only queries your DNS provider:

• Zero inbound ports required: your FileMaker Server stays completely private behind your firewall.
• Private IP friendly: your hostname can resolve to a local 192.168.x.x address (or use split-horizon DNS) while still getting a publicly trusted certificate.
• No manual keychain trust: every FileMaker Pro, FileMaker Go, and WebDirect client trusts the certificate out of the box.

👉 Want to see the whole flow before diving in? Click here to open the interactive certificate lifecycle map — a visual walkthrough of every step, from the ACME DNS challenge to the Apache and Database Server reloads.

What’s in the guide (and why “set and forget” is harder than it looks) #

Getting the first certificate with certbot and a DNS plugin (like IONOS, Cloudflare, or Route53) is only half the battle. Making unattended 90-day renewals actually work on macOS FileMaker Server has a few sharp edges we learned the hard way in production:

1. Headless fmsadmin prompts: under launchd, fmsadmin certificate import has no TTY — if credentials aren’t passed explicitly from a secure root-only environment file, the deploy hook silently aborts.
2. Two certificate consumers: importing the cert isn’t enough. Both FMS’s bundled Apache (port 443) and the Database Server (port 5003) cache the certificate independently and require atomic launchctl kickstart -k reloads.
3. Silent renewal failures: without automated verification checking both ports 443 and 5003 after renewal, you won’t know a hook failed until the old certificate expires 30 days later.

Get the full guide and scripts #

We’ve open-sourced our complete, battle-tested setup in fms-letsencrypt-dns01, including:

• A step-by-step guide for macOS FileMaker Server using Certbot in an isolated Python virtual environment (/opt/certbot-venv) that survives Homebrew upgrades.
• Ready-to-use deploy hook and manual import scripts that handle fmsadmin credentials and cleanly reload both Apache and the Database Server.
• launchd plists for automated daily renewal checks and daily email health reports verifying certificate expiry across ports 443 and 5003.
• A real-world incident post-mortem detailing every failure mode the scripts are designed to prevent.
• An interactive certificate lifecycle map — click through it to trace the full renewal flow step by step.

👉 Read the full guide and grab the scripts on GitHub