Bind 437 to one acquired credential
Record the timestamp and timezone, endpoint or trunk, Call-ID, CSeq, every Identity field and credential URL, retrieval or cache result, acquired credential digest, responder, complete 437 and any STIR Reason value. Establish whether Asterisk generated the error while verifying an inbound INVITE or received it from another verifier on an outbound leg.
Do not begin with trust-store edits until the trace shows that at least one credential was acquired. A DNS, connection, TLS or HTTP failure remains a 436 investigation. If several Identity fields exist, retain each field, credential and result because a supported trusted sibling changes the request-level conclusion.
Identify the running verifier and trust inputs
Record core show version, loaded STIR/SHAKEN modules, the endpoint's stir_shaken_profile and its effective profile. Inspect the loaded ca_file or hashed ca_path, load_system_certs, configured CRL inputs and any untrusted certificates used only to verify a separately signed CRL. Source files are not proof that Asterisk loaded a usable path or hash.
Asterisk's deployment guide says the CA inputs must include the root, issuer and intermediate certificates needed for the retrieved x5u certificate. Keep a CRL-signing certificate in untrusted_cert_file or untrusted_cert_path only for its documented role; do not convert it into a trust anchor.
Separate chain construction from revocation
Preserve the leaf, intermediates, root candidate, key and signature algorithms, validity dates and verifier error. Check file readability and PEM parsing, then whether the configured chain reaches the intended trust anchor. Only after chain construction succeeds should a CRL failure be assigned to its issuer, distribution, signature, format, hashing or freshness owner.
Asterisk documents stir_shaken verify certificate_file beginning with 18.25.0, 20.10.0, 21.5.0 and certified 20.7-cert2. Use it only when the exact running release provides it; on earlier releases, retain normal runtime evidence rather than assuming the command exists.
Stop before PASSporT validity
If Asterisk cannot anchor or support the acquired credential, remain on 437 evidence. If the credential is supported and trusted but the PASSporT signature, required claims, identity reconstruction or caller-ID comparison fails, investigate 438. Freshness failures involving SIP Date or iat retain their own evidence and policy.
The STIR_SHAKEN() dialplan function exposes the per-channel identity, attestation and verification result when calls continue. Preserve that result alongside failure_action and any RFC 9410 Reason response without treating dialplan continuation as successful verification.
Correct narrowly and retest in order
Correct only the demonstrated owner: provider CA bundle, missing intermediate, wrong hashed path, unavailable or invalid CRL, unsupported credential algorithm or release capability. Preserve the prior files, permissions and effective profile with a rollback trigger. Do not trust an arbitrary leaf, disable revocation or weaken algorithms simply to remove 437.
Use an authorized non-emergency test identity. Confirm retrieval, chain and algorithm support, revocation result, PASSporT verification and local authorization as separate acceptance steps. No PBX, verifier, provider, CA, certificate, CRL, algorithm, 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>
# Where supported by this exact release:
stir_shaken verify certificate_file <certificate.pem>
pjsip set logger on
# Reproduce one authorized non-emergency request and capture 437 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.