V2X Certificate Chain Validator
Walk an IEEE 1609.2 V2X certificate chain end-entity → intermediate → root, parse each link, and report on structural consistency. Confirms parse success, issuer linkage by HashedId8 (computed with WebCrypto SHA-256), validity windows, and supported signature schemes. Structural validation only. Cryptographic signature verification is not performed by this tool.
Input — chain certificates
Validation report
What the validator checks — and what it doesn't
What it checks
- Each certificate parses cleanly against the IEEE 1609.2 schema subset our decoder supports.
- The lower certificate's issuer field matches the upper certificate's HashedId8 (last 8 bytes of SHA-256 over the upper certificate's bytes).
- The validity period (Time32 start + Duration) is structurally well-formed.
- The signature CHOICE selects a supported ECDSA scheme (NIST P-256 / P-384, Brainpool P-256r1 / P-384r1).
What it does not check
- Whether the signature on each certificate is cryptographically valid.
- Whether any certificate in the chain is revoked.
- Whether the EE certificate's permissions (PSID/SSP) are appropriate for any specific V2X service.
- Whether the current time falls inside the validity window.
Privacy
All parsing and SHA-256 hashing happens in your browser. Certificate bytes never leave this page. The WebCrypto SubtleCrypto interface is used for the HashedId8 derivation only.
FAQ
Why is HashedId8 derived from SHA-256 of the certificate bytes?
IEEE 1609.2 §6.4.3 defines HashedId8 as the last 8 bytes of the cryptographic hash (SHA-256, or SHA-384 for the larger algorithm family) of the COER-encoded issuer certificate. It is a compact reference to "which certificate is the issuer", small enough to embed in every signed message that uses certificate-digest form (rather than carrying the full issuer certificate). The chain validator computes the same hash over the bytes you supply and compares it against what the lower certificate claims.
Why doesn't the tool verify the signature itself?
Signature verification requires the issuer's public verification key, which is extracted from the issuer's verifyKeyIndicator field. That is decodable here, but assembling a real ECDSA verification — including correct point-decompression for compressed-y curve points, correct hash input domain, and correct handling of implicit certificates' reconstructed public key — is enough surface that we have explicitly scoped this tool as structural only to avoid offering a false sense of cryptographic validation. Use a conformance test bench (or implement against an ETSI / IEEE published test vector set) for real verification.
Can I supply more than 3 levels of chain?
Not in this build. V2X PKI chains are typically 2 or 3 levels (Root CA → AA → PC, or Root CA → EA → EC). The 3-input form matches that. If you need deeper chains, the underlying parser can handle them — ping us via contact with a use case.
Related
IEEE 1609.2 parser
Full field-tree decoding for a single certificate. Useful for inspecting a chain link in detail before running the validator.
V2X PKI reference
Technical companion: certificate format, EC vs PC, Butterfly Key Expansion, India TRAI CP 30/04/2026 context.
V2X security architecture
Solution view: EA/AA, manufacturing-time provisioning, lifecycle, scope discipline.