Bind 436 to one request and verifier
Record the timestamp and timezone, Request-URI, endpoint or trunk, Call-ID, CSeq, top Via branch, From, P-Asserted-Identity, Date, every Identity field and credential URL, responding element, complete 436 and any STIR Reason value. Establish whether Asterisk generated the error while verifying an inbound INVITE or received it from an upstream verifier on an outbound leg.
Use the PJSIP logger only for one authorized bounded reproduction, then disable it and protect numbers, PASSporTs and certificate URLs. If multiple Identity fields exist, retain each field-to-result relationship rather than assuming the first URL caused the final response.
Confirm the loaded verification path
Record core show version, loaded STIR/SHAKEN modules, the PJSIP endpoint's stir_shaken_profile and its effective profile. Current Asterisk verification requires an active verification object or profile behavior and follows its failure action. A saved file is not proof that the running endpoint uses it, and a later branch's options must not be assumed on an older release.
If failure_action rejects, Asterisk can return an RFC 8224 4xx. With continue_return_reason, it can continue into the dialplan and report the corresponding error in a later Reason header; use_rfc9410_responses changes the protocol token to STIR. Preserve those policy results separately from credential retrieval.
Trace x5u policy, cache and retrieval
Asterisk checks the certificate URL against scheme, port, path and address restrictions before retrieval. It then checks its certificate cache and, when necessary, retrieves the credential within curl_timeout. Preserve the exact URL, ACL decision, cache hit or miss, cached-object age, resolver result, selected address, connection and HTTP outcome from the PBX network position.
Do not enable relax_x5u_port_scheme_restrictions or relax_x5u_path_restrictions as a production fix. Asterisk warns those testing controls have serious security implications. Keep the default protection against special-purpose addresses and investigate legitimate provider ranges explicitly so a caller-controlled URL cannot become an SSRF path.
Stop at the first proven boundary
If no credential bytes were acquired, remain on 436 evidence: DNS, routing, TLS or HTTP failure, timeout, URL policy, cache state or signer publication. If bytes were acquired but the issuing CA or algorithm is unsupported, investigate 437. If a supported credential is available but the PASSporT or signature is invalid, investigate 438. CA files, intermediate chains, CRLs, identity timestamps and caller-ID comparison are later checks and should not be used to explain a failed fetch without evidence.
A public browser fetch from a laptop does not reproduce the PBX resolver, egress ACL, address policy or cache. Likewise, a cache hit does not prove that a fresh retrieval would succeed. Preserve both runtime and network context.
Correct narrowly and verify retrieval safely
Correct only the demonstrated owner: authentication-service URL, certificate hosting, DNS, TLS service, outbound PBX network policy, Asterisk x5u ACL or stale cache. Preserve the previous profile, ACL and cache evidence with a rollback trigger. Do not expose private keys, broaden private-address access, disable TLS validation or copy another provider's certificate to clear the response.
Use an authorized non-emergency test identity and the provider's current validation procedure. Confirm retrieval from the actual verifier path, then separately confirm trust and signature results. No PBX, verifier, provider, URL, certificate, cache, Identity header or live call was tested for this guide.
core show version
module show like stir
stir_shaken show eprofiles
pjsip show endpoint <endpoint>
pjsip set logger on
# Reproduce one authorized non-emergency request and capture Identity, 436 or STIR Reason.
pjsip set logger offSources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk STIR/SHAKEN deployment guide ↗
- Asterisk res_stir_shaken configuration reference ↗
- Asterisk STIR_SHAKEN dialplan function ↗
- IETF RFC 8224: Authenticated Identity Management in SIP ↗
- IETF RFC 9410: Handling Identity Header Errors for STIR ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.