Establish the refactored implementation and loaded objects
Asterisk's deployment guide says its STIR/SHAKEN documentation describes the refactor delivered in the first quarter of 2024 and that the earlier implementation was only partially functional and not interoperable. Preserve the running Asterisk maintenance version, loaded modules, stir_shaken.conf owner and PJSIP endpoint state before applying an example from another branch.
The refactored model has one attestation object, one verification object, telephone-number objects and endpoint-selectable profile objects. Asterisk builds effective profiles from those inputs and exposes them with stir_shaken show eprofiles. A saved profile name is not proof that the endpoint loaded it or that an INVITE used it.
Separate outbound attestation from number authority
Outbound attestation creates an Identity header using a channel caller number, attestation level, destination, time, certificate URL and signature. The A, B and C levels state different relationships to the originating customer and calling number; they are not quality grades and they do not independently establish that an organization is authorized to sign for a number. Bind the chosen level, private key and public certificate to written authority from the issuing or upstream party.
Asterisk looks up the channel caller number in a TN object. Its current guide warns that manually changing From or P-Asserted-Identity without keeping the channel value aligned can make the Identity header disagree with the SIP identity and fail remote validation. Preserve the channel caller ID, first outbound INVITE and selected TN and effective profile together.
Protect signing material and the public certificate path
The private key file must be owned and readable only as required by the Asterisk process; the certificate published at public_cert_url must never contain the private key. Asterisk can optionally fetch the configured public certificate before loading a TN and refuse it when the resource cannot be retrieved or is outside its validity window, but that startup check is not a provider authorization decision or a successful remote verification.
Record key custody, issuance, rotation, revocation and certificate hosting separately. Confirm DNS, HTTPS, certificate availability and system time through a controlled maintenance procedure. Do not paste a production key, PASSporT or complete Identity header into shared tickets or editorial evidence.
Constrain inbound certificate retrieval and verification
Incoming verification can retrieve the certificate named by the Identity header's x5u value, build a configured CA chain, consult configured CRLs, enforce time windows and cache certificates. That outbound retrieval is also an SSRF boundary. Keep the documented HTTPS, port, path and special-purpose-address restrictions enabled in production and use explicit x5u ACL controls when the design requires a narrower policy. The relaxation options are documented for testing and carry security warnings.
Preserve the effective verification profile, received Identity and Date headers, DNS result, fetch target, certificate chain, CRL material, cache state and individual verification result. A parsed header, fetched certificate or valid signature alone is not the complete verification process.
Keep Asterisk's documented verification limits visible
The current Asterisk guide states that it does not validate the destination telephone number in the SIP To header against the PASSporT destination. It also describes limited certificate checks, no automatic retrieval of the CRL referenced by the certificate, and no available mechanism to prove that a service-provider code in a certificate has authority over a particular telephone number. Asterisk supports the full PASSporT form for this path rather than the compact form.
These are implementation boundaries, not instructions to accept every result or to bolt on unreviewed header logic. Recheck the exact installed branch and provider architecture because these statements are version-sensitive. Document compensating policy outside Asterisk rather than describing the deployment as complete end-to-end caller authentication.
Make the verification result and call action separate decisions
Asterisk's verification failure_action can continue, reject, or continue while returning reason information; the documented default is continue. The STIR_SHAKEN() dialplan function exposes the number of identities and per-identity value, attestation and verification result. A passing identity is evidence about one signed assertion, not proof that the caller is benign; a failed or absent identity does not by itself identify fraud.
If policy rejects an incoming PJSIP request, PJSIPHangup() can send a selected final SIP response only before another final response such as answer has been sent. Use the 428 investigation for a missing required identity and the 438 investigation for a failed identity. Test provider-approved ordinary calls for the intended continue, reason and reject paths and preserve the wire response, dialplan result and user-visible outcome separately. No identity, certificate, call or policy result was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk STIR/SHAKEN deployment guide ↗
- Asterisk 22 res_stir_shaken reference ↗
- Asterisk 22 res_pjsip endpoint reference ↗
- Asterisk 22 STIR_SHAKEN dialplan function ↗
- Asterisk 22 PJSIPHangup application ↗
- RFC 8224: authenticated identity management in SIP ↗
- RFC 8225: PASSporT ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.