Inventory certificate, key, transport and consumers
Record the authoritative management layer, Asterisk version, PJSIP transport name, protocol and bind, certificate and private-key paths, CA source, verification settings, endpoints and outbound registrations that use the transport, and any persistent connections. Inspect the running transport and listener rather than inferring them from a saved file.
Preserve the served serial, names, issuer, validity and chain from an authorized client on each required path. A certificate file, transport object, listening socket, selected endpoint and negotiated TLS session are separate evidence. Keep signaling TLS distinct from endpoint media encryption.
Stage matching material without exposing the key
Validate the new certificate's subject-alt names, dates, chain and match to the private key before activation. Confirm that the Asterisk service account can read the required files without broadening permissions or copying key contents into logs. Retain the known-good files and a supported rollback operation.
Use the hostname the peer actually validates, not an administrative label. Establish who controls each phone, trunk or proxy trust store and whether a public or private CA is expected. Do not disable verify_server, name validation or chain validation to make unproven replacement material connect.
Use the exact reload boundary
Asterisk 20 added the ability for res_pjsip TLS transports to reload certificate and private-key files when their configured filenames do not change. The current transport reference states the same filename constraint and separately documents allow_reload, which defaults to no because transport reload can disrupt in-progress calls.
Treat file-content reload, transport-object reload and a complete restart as different operations. If filenames, bind, protocol, CA, verification or other transport settings change, consult the installed branch and management layer. On FreePBX, use supported generated configuration and its activation workflow rather than editing managed files as a durable repair.
Keep inbound and outbound verification roles distinct
For an inbound TLS listener, prove the certificate chain served to the client and any configured client-certificate requirement. For an outbound trunk or registration, prove the remote server chain and the local transport's verify_server, CA and name behavior. Asterisk exposes verify_client, require_client_cert and verify_server as distinct transport controls.
Wildcard acceptance is a separate option used with server verification and has bounded matching semantics. Do not generalize one successful wildcard, private-CA or mutual-TLS test to every peer. Record the actual SNI or target name, local and remote signaling tuples and negotiated session.
Verify TLS and media as different layers
After activation, confirm the peer reached the intended TLS listener or outbound connection, validated the expected certificate and recovered registration or trunk state. Then place bounded calls and inspect signaling transport, SDP and media on each leg. Asterisk documents SDES and DTLS as endpoint media-encryption choices; neither follows automatically from a TLS transport.
For SDES, protect the signaling path that carries the SDP keying material. For DTLS-SRTP, prove the media-leg handshake and negotiated result. A secure indicator in a client is supporting evidence for that client session, not proof of end-to-end encryption through a terminating PBX or PSTN path.
Close with served-state and rollback evidence
Record the activation operation and time, loaded transport, listener, served serial and chain, endpoint and trunk recovery, inbound and outbound call results, media result, existing-call impact and neighboring unaffected path. Check for certificate, name, chain or private-key errors and for persistent connections that may still carry earlier session state.
If acceptance fails, restore the known-good material and configuration through the same owner, perform the supported activation, and verify the prior served state. Remove temporary diagnostics and protect retired keys according to policy. This workflow is documentation-derived and no PBX, certificate, transport, session or call was tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk current res_pjsip transport reference ↗
- Asterisk PJSIP configuration objects and relationships ↗
- Asterisk 20 TLS certificate reload notes ↗
- Asterisk 22 TransportDetail fields ↗
- FreePBX Certificate Manager release/17.0 metadata ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.