Separate the certificate object from every consumer
Certificate Management can hold generated, uploaded, CSR-derived or ACME-issued material, but a managed row is not the same as the default certificate, a service-specific binding, a loaded Asterisk transport or the certificate a client received. Record the certificate identity and each intended consumer: Admin HTTPS, UCP or another web listener, reverse proxy, PJSIP TLS transport, WebSocket service, provisioning path or application.
Preserve serial, subject and subject-alt names, issuer, validity interval, chain, public-key fingerprint and matching private-key evidence without copying the private key into the change record. Use the hostname that each client actually connects to. A valid certificate for a different name or consumer is not repaired by marking it default.
Choose an acquisition path without confusing it with activation
Sangoma documents certificate generation and Let's Encrypt, while its Certificate Management API exposes distinct operations to generate a CSR, upload a certificate, fetch a CSR certificate, update the default and delete objects. The fwconsole certificate command similarly exposes list, update, import, generate and default operations. Those are lifecycle controls; none alone establishes which service loaded the result.
For an uploaded or CSR-returned certificate, prove that the certificate matches the retained private key and that the required intermediate chain is present. For Let's Encrypt, preserve domain validation and issuance separately from import and activation. Do not delete the last usable object or key until every required consumer has passed acceptance.
Prove identity, time and trust from the client's path
Validate the exact DNS name, subject-alt-name match, full served chain, issuer trust, current time and validity interval from a controlled client on the intended network path. A green row in Certificate Management does not prove that a reverse proxy, browser, phone or remote trunk reaches the same listener or trust store.
Treat self-signed, private-CA and publicly trusted certificates as different distribution models. A private CA can be appropriate only when its trust anchor is delivered and governed on every authorized client. Do not disable hostname or chain validation as a permanent workaround for a missing intermediate, clock error, wrong listener or stale binding.
Keep signaling TLS, DTLS and SRTP distinct
Certificate Manager metadata describes TLS and DTLS uses, but the selected certificate does not automatically enable protected signaling or media. Asterisk documents a TLS transport's certificate and private-key files separately, while endpoint media policy can be sdes or dtls. SDES places media keys in SDP and therefore depends on protecting the signaling leg; DTLS-SRTP negotiates its own media-keying exchange.
Record protection per call leg. TLS registration does not prove SRTP, an SRTP lock indicator does not prove certificate validation, and a PBX that terminates signaling or media is not an end-to-end encryption guarantee. Test each trunk and endpoint policy rather than transferring a result between them.
Version the reload and service-activation path
Current release/17.0 metadata lists Certificate Manager 17.0.3.15 and records a PJSIP-reload fix for certificate updates; 17.0.3.14 records an HAProxy reload integration fix for Let's Encrypt renewal. These changelog entries are reasons to capture the installed module version and the affected consumer, not proof that an uninspected PBX reloaded either service.
Asterisk permits certificate and private-key file reload when configured filenames remain unchanged, but allow_reload defaults to no because transport reload can disrupt calls. If a filename, bind, protocol or trust policy changes, use the installed platform's supported activation path and a maintenance plan. Do not enable reload during an incident merely to avoid an approved restart boundary.
Accept the served state and preserve rollback
After the supported activation, inspect each consumer and observe the served serial, names, issuer and chain from an authorized client. For PJSIP, confirm the loaded transport, listener, registration or trunk recovery and bounded calls; verify signaling transport and media protection independently. Include one neighboring unaffected service and any persistent connection that may retain old state.
Retain the previous certificate, key, bindings and activation record through the acceptance window. Roll back through the same supported owner if a required client cannot validate the chain or a service fails to load, then prove the prior served state. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX Certificate Management ↗
- 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.