VoIP.info Diagnostic

FreePBX unsigned or altered module warning

Preserve the signature evidence, distinguish an unsigned module from altered release files and recover through a supported, bounded module operation.

Reviewed 2026-09-26FreePBX 17 on Debian 12; current installer and Sangoma module-signing and fwconsole references reviewed September 26, 2026; no PBX, module or call workflow lab testedAdvancedDocumentation based · not lab tested

Keep the warning as evidence

FreePBX module signing checks whether installed module files match the signed release. Open the warning details and record its timestamp, module name and version, whether it says Unsigned or Altered, and every reported file before clearing a notification or changing the module. Correlate that evidence with the last module update, restore, migration, package operation or approved local edit.

An Unsigned result means the module is not authorized through the FreePBX signing process. An Altered result means files differ from the signed release. Neither label proves the operator's intent, and a green service dashboard does not make the integrity finding harmless.

Inspect without erasing the cause

Use Module Admin for the normal module view. For a controlled console check, Sangoma documents fwconsole ma info <module> and fwconsole ma list; fwconsole notification --list can expose notices such as FW_UNSIGNED. Preserve the output with the installed FreePBX, Debian, Asterisk and module versions. A notification command reports state; deleting a notice does not repair the files that caused it.

Do not disable invalid-signature checking on a production PBX. Do not edit the signature manifest, use force flags, replace files from an unrelated release or apply recursive ownership changes merely to remove the banner. Sangoma warns that the -f module option skips dependency and status checks.

Decide whether the code is expected

For a locally developed or third-party module, identify its owner, source repository, approved artifact, signing path and deployment record. Self-signing does not turn unknown code into a trusted FreePBX release. Quarantine or remove an unexpected module through an approved incident process rather than assuming that it is a harmless customization.

For an Altered published module, compare the file list with the change record and known-good artifact. Preserve a backup or snapshot outside the PBX failure domain before replacement. If the difference was intentional, document how that customization will be rebuilt and reviewed instead of retaining an unexplained production edit.

Recover one module through a supported path

Use Module Admin normally, or the documented fwconsole ma operation for the exact module and installed release. Sangoma documents fwconsole ma refreshsignatures as a redownload of modules with invalid signatures; the current FreePBX 17 Debian installer also invokes that command. Treat it as content replacement, not a read-only signature refresh: schedule it, preserve the evidence and make sure the recovery path can restore the prior state.

Do not copy a historical upgrade recipe blindly. Sangoma's signing page includes an older upgrade example with fwconsole chown, signature refresh and reload, but that does not establish blanket ownership changes as the right fix for every current warning. Use ownership repair only when the installed-version documentation and file evidence identify ownership as the fault.

Verify integrity and phone service separately

Recheck the exact module status and signature notice, then apply or reload configuration only when the supported operation requires it. Verify the affected feature and a small regression set: internal calls, one inbound and outbound route, voicemail or IVR when relevant, registrations and emergency-routing prerequisites without placing an unauthorized emergency test call. Keep rollback criteria and the captured before-and-after module versions in the change record.

A cleared warning establishes neither code provenance nor call service by itself. No PBX, module, file, update, signature, registration, route or live-call behavior was tested for this guide; interface labels and command availability can vary with the installed FreePBX and module versions.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.