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.
How to use this tool
What it does
Validates an IEEE 1609.2 certificate chain up to a trusted V2X root.
When to use it
Use it when a V2X message fails verification and you need to see where the certificate chain breaks.
Worked example
Load a pseudonym, its issuer and the root to confirm each link and its permissions.
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.
Frequently asked questions
What does this validator check?
Structure: that each certificate parses, that issuer linkage by HashedId8 resolves up the chain, that validity periods are coherent, and that signature schemes are consistent.
What does it deliberately not check?
It does not verify signatures cryptographically and does not consult a CRL or CTL. A structurally valid chain can still be revoked or forged, so this is a diagnostic rather than a trust decision.
What does the V2X chain look like?
Root CA, then an Enrolment Authority and an Authorisation Authority, then the end-entity credential — an enrolment credential from the EA or a pseudonym certificate from the AA.
Why does my chain fail to link?
Almost always a HashedId8 that matches no supplied certificate, meaning an intermediate is missing from the bundle. Order does not matter here; presence does.
Does anything I paste leave my browser?
Nothing. The tool is entirely client-side: the page ships a static script, does no network calls, and never transmits what you paste. You can confirm it by opening the network tab, or by loading the page and then going offline.