Classify the failure before requesting another certificate
Start with the exact FQDN, certificate entry, serial, issuer, names, not-before and not-after dates, intended service and first error. A failed ACME validation, successful issuance that is absent from Certificate Manager, a new stored certificate that was not selected for Apache or Asterisk, and a client that still sees an old chain are different incidents. Query the intended HTTPS or SIP listener from a controlled client and compare the presented certificate with the FreePBX record.
Preserve the last successful renewal time, module versions, public DNS answers, NAT destination, port owner and recent firewall or reverse-proxy changes. Do not delete the last usable certificate, self-signed CA, private key or service binding while evidence is incomplete. A browser warning after renewal does not by itself prove that issuance failed.
Prove the HTTP-01 path from every documented vantage point
FreePBX Certificate Management uses Let's Encrypt HTTP-01 on port 80. Sangoma documents three retrieval paths: the PBX must fetch its own token through the configured FQDN, Sangoma mirror servers must resolve and fetch it, and Let's Encrypt validation systems must fetch it from the public Internet. Let's Encrypt documents that HTTP-01 places a token below /.well-known/acme-challenge/, can validate from multiple network vantage points and cannot use an arbitrary port.
Check authoritative public DNS, both address families if published, port-80 NAT, the selected Apache or LetsEncrypt-only listener, reverse-proxy or CDN routing and the exact challenge path. Test the token path without exposing the Admin interface more broadly than the supported design. A successful local request does not prove the public or mirror path, while one external success does not prove every published address or validation vantage point.
Keep FreePBX firewall automation and external controls separate
Sangoma says current PBX Firewall and Certificate Management modules dynamically allow the token path during creation or renewal and then restore the prior local rule. Alternate host firewalls, upstream appliances, provider firewalls and NAT remain outside that automation. The Commercial System Admin module can assign a LetsEncrypt-only service to port 80, which denies unrelated file requests; that listener is not HTTPS.
Record which component owns port 80 and which device performs each translation or filter. If using the documented manual FreePBX firewall rule, scope it to the renewal window and return it to the prior state after the controlled attempt. Do not solve a challenge failure by exposing SSH, the whole Admin GUI or unneeded management ports.
Capture one controlled renewal attempt
Confirm that Certificate Management is enabled, the FQDN matches the intended public record, system time is credible and the challenge listener is ready. Sangoma's FreePBX 15+ command reference documents certificate generation through fwconsole certificates --generate --type=le with the hostname and contact fields; use the supported GUI or version-appropriate CLI to preserve the complete error, challenge URL and timing. Redact account identifiers and private material before sharing logs.
Do not loop forced requests while DNS or reachability remains wrong. Let's Encrypt renewal repeats domain validation and issuance, and failed validations require another request; repeated attempts can consume rate limits and bury the first useful error. Correct one evidenced cause, then make one bounded retry. A certificate returned by the CA proves issuance, not that every PBX service loaded it.
Activate the new certificate for each intended service
FreePBX documents the Certificate Manager default as an Advanced Settings and integration selection, while System Admin has a separate HTTPS Setup certificate installation for Apache. Compare the new stored certificate with each configured consumer: Admin HTTPS, UCP or other web service, Asterisk PJSIP TLS transport, WebSocket listener, provisioning service and any Sangoma application in scope. Use supported FreePBX controls rather than editing generated configuration as a durable fix.
For Asterisk, a certificate file on disk and a selected FreePBX object are not proof that the running transport presents the new chain. Follow the Asterisk certificate-rotation guide and TLS certificate-failure investigation for the service activation boundary. Record the presented serial, chain and name from every required listener.
Close the incident with service-specific acceptance
After the controlled renewal and activation, verify the Admin hostname, browser chain, UCP if used, one endpoint TLS registration, one authorized inbound and outbound call, and SRTP separately where required. Check scheduled renewal ownership, monitoring and an alert that observes the served certificate rather than only a file date. Remove temporary tracing and restore the documented firewall state.
If renewal cannot be restored before expiry, use the organization's approved continuity path and a separately obtained or uploaded certificate only with verified key, chain, hostname and service activation. Do not disable hostname or chain validation as a production workaround. No PBX, domain, firewall, NAT, module, ACME request, certificate, web service, registration, media path or live call was tested for this guide.
Version the consumer reload before blaming renewal
Current release/17.0 metadata lists Certificate Manager 17.0.3.15 with a PJSIP-reload fix for certificate updates and 17.0.3.14 with an HAProxy reload integration fix for Let's Encrypt renewal. Record the installed module version, certificate serial before and after issuance, selected service binding, reload or restart result and served serial. A successful renewal on an older or otherwise different installation can leave one consumer serving the prior certificate.
Correct the installed and supported activation owner rather than forcing another ACME order. Compare Certificate Manager storage, default selection, System Admin or proxy selection, PJSIP transport files and the certificate observed from each required listener. Repository history is not a local upgrade recommendation; assess module dependencies, backup and change window through normal administration.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX Certificate Management ↗
- Sangoma FreePBX System Admin Port Management ↗
- Sangoma FreePBX 15+ fwconsole certificate commands ↗
- Let's Encrypt challenge types ↗
- Let's Encrypt issuance and renewal process ↗
- Let's Encrypt rate limits ↗
- Sangoma Certificate Management GraphQL APIs ↗
- Sangoma FreePBX fwconsole certificate commands ↗
- FreePBX Certificate Manager release/17.0 metadata ↗
- Asterisk current res_pjsip transport reference ↗
- Asterisk 20 TLS certificate reload notes ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.