Si administras FileMaker Server en una red interna, seguro que te has topado con el muro del SSL.

Los flujos de trabajo modernos de FileMaker exigen un certificado TLS válido y de confianza pública: la Data API, OData, WebDirect y las conexiones cifradas de clientes por el puerto 5003 dependen de él. Incluso las llamadas fetch() dentro de los Web Viewers fallan silenciosamente si el sistema operativo no confía en tu certificado.

Por qué falla el botón integrado de Let’s Encrypt #

FileMaker Server incluye un práctico botón “Request Let’s Encrypt Certificate” en la Admin Console. El problema es que se basa en el reto HTTP-01 de Let’s Encrypt, que exige que Let’s Encrypt pueda alcanzar tu servidor desde Internet público por el puerto 80.

Si tu FileMaker Server tiene una IP privada de LAN, o si los puertos 80 y 443 de tu router ya están reservados para otro servidor web, HTTP-01 no puede funcionar nunca. Pulsar ese botón solo producirá un tiempo de espera agotado y quemará los límites de validación de Let’s Encrypt.

La solución: validación DNS-01 #

En lugar de demostrar la propiedad del dominio por HTTP, el reto DNS-01 de Let’s Encrypt verifica un registro TXT temporal _acme-challenge en la zona DNS de tu dominio.

Como Let’s Encrypt solo consulta a tu proveedor de DNS:

• Cero puertos de entrada: tu FileMaker Server permanece completamente privado detrás del cortafuegos.
• Compatible con IPs privadas: tu nombre de host puede resolver a una dirección local 192.168.x.x (o usar DNS de horizonte dividido) y seguir obteniendo un certificado de confianza pública.
• Sin confianza manual en el llavero: todos los clientes de FileMaker Pro, FileMaker Go y WebDirect confían en el certificado desde el primer momento.

👉 ¿Quieres ver todo el flujo antes de empezar? Haz clic aquí para abrir el mapa interactivo del ciclo de vida del certificado — un recorrido visual por cada paso, desde el reto DNS de ACME hasta las recargas de Apache y del Database Server.

Qué contiene la guía (y por qué “instalar y olvidarse” es más difícil de lo que parece) #

Conseguir el primer certificado con certbot y un plugin de DNS (como IONOS, Cloudflare o Route53) es solo la mitad de la batalla. Hacer que las renovaciones desatendidas de 90 días funcionen de verdad en FileMaker Server sobre macOS tiene algunas aristas que aprendimos por las malas en producción:

1. Prompts de fmsadmin sin terminal: bajo launchd, fmsadmin certificate import no tiene TTY — si las credenciales no se pasan explícitamente desde un archivo de entorno seguro accesible solo por root, el deploy hook aborta silenciosamente.
2. Dos consumidores del certificado: importar el certificado no basta. Tanto el Apache integrado de FMS (puerto 443) como el Database Server (puerto 5003) almacenan el certificado en caché de forma independiente y requieren recargas atómicas con launchctl kickstart -k.
3. Fallos de renovación silenciosos: sin una verificación automática que compruebe ambos puertos, 443 y 5003, tras cada renovación, no sabrás que un hook falló hasta que el certificado antiguo caduque 30 días después.

Consigue la guía completa y los scripts #

Hemos publicado como código abierto nuestra configuración completa y probada en producción en fms-letsencrypt-dns01, que incluye:

• Una guía paso a paso para FileMaker Server en macOS usando Certbot en un entorno virtual de Python aislado (/opt/certbot-venv) que sobrevive a las actualizaciones de Homebrew.
• Scripts de deploy hook y de importación manual listos para usar que gestionan las credenciales de fmsadmin y recargan limpiamente tanto Apache como el Database Server.
• Plists de launchd para comprobaciones diarias de renovación e informes diarios de salud por correo que verifican la caducidad del certificado en los puertos 443 y 5003.
• Una autopsia de un incidente real que detalla cada modo de fallo que los scripts están diseñados para prevenir.
• Un mapa interactivo del ciclo de vida del certificado — haz clic para recorrer todo el flujo de renovación paso a paso.

👉 Lee la guía completa y descarga los scripts en GitHub