Start only after credential acquisition
RFC 8224 defines 437 Unsupported Credential when a verification service acquired, or already holds, the credential referenced by at least one Identity field but cannot support the available credential. Examples include not trusting its issuing certification authority or not supporting the algorithm with which the credential was signed. Preserve every Identity field, credential reference, acquired object, responder and exact result.
Do not use 437 for a credential that could not be fetched at all; that is the 436 acquisition boundary. Do not treat it as proof that the PASSporT signature, calling identity, attestation or call authorization is invalid. Those are later and separate decisions.
Prove the credential and chain presented
Record the exact credential bytes or digest, format, subject and issuer, validity interval, key and signature algorithms, complete presented or configured chain, trust anchor and revocation inputs. A verifier can retrieve a leaf certificate successfully yet lack its intermediate, reject its issuing CA or not implement its algorithm. A browser's trust result does not establish the SIP verifier's trust store or algorithm support.
Multiple Identity fields can reference different credentials. A single unsupported credential does not justify 437 if another usable field has a supported credential. Preserve field-level outcomes instead of replacing the first certificate until the response disappears.
Keep trust, revocation and signature validity separate
Trust-chain construction asks whether the credential can be anchored under verifier policy. Revocation checking asks whether the credential or chain remains acceptable under configured CRLs or other applicable mechanisms. PASSporT verification asks whether the supported credential validates the signed object and its required claims. These checks can fail independently.
RFC 8224's 438 covers the absence of any valid supported PASSporT; 437 covers credential support. An expired or not-yet-valid credential may be reported through implementation-specific verification evidence, so retain the verifier's exact reason rather than assigning a status from certificate dates alone.
Repair the trust relationship, not the symptom
Correction belongs to the signer, credential issuer, provider trust programme or verifier configuration owner. Do not import an arbitrary leaf as a trust anchor, disable revocation, enable obsolete algorithms or copy another provider's CA bundle. Confirm the expected certificate policy and supported algorithms with the responsible provider.
Use an authorized non-emergency identity to retest. Verify credential acquisition first, then chain and algorithm support, then PASSporT validation and local authorization. The Asterisk PJSIP investigation follows those boundaries without representing a trust relationship as tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 8224: Authenticated Identity Management in SIP ↗
- IETF RFC 9410: Handling Identity Header Errors for STIR ↗
- IANA SIP response-code registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.