Tools that run in your browser and send nothing anywhere.
The AmbiSecure engineering team maintains a set of client-side developer tools and reference databases. Every one runs entirely inside the browser — no inputs leave the page, no accounts, no logging, no analytics on tool inputs. Paste a real certificate into them.
Two tools built for this certificate format specifically.
All of these live on the AmbiSecure engineering tools hub, which is where the whole collection is indexed.
| Tool | What it does |
|---|---|
| IEEE 1609.2 certificate parser | Client-side COER decoder for V2X and ITS certificates. Hex, Base64 or PEM input; labelled field tree with a standards reference on every row; synthetic example certificates included. |
| V2X certificate chain validator | End-entity → intermediate → root. Parses each link, computes HashedId8 via WebCrypto SHA-256, checks linkage. Structural validation only — cryptographic signature verification is explicitly out of scope, and it does not constitute ETSI or IEEE compliance testing. |
The field definitions behind the parser are on the V2X PKI page.
General-purpose, and useful alongside the V2X pair.
For anyone working on the device side of the boundary.
APDU parser · APDU builder · TLV parser · ATR parser · SCP03 helper · GlobalPlatform status · JavaCard CAP inspector · Key diversification
The provisioning architecture these correspond to is described on hardware root of trust.
Structured, field-by-field standards references.
A certificate is not a thing you upload to a stranger.
Every tool linked from this page runs entirely inside the browser. Nothing is posted to a server, nothing is logged, and there is no account. That is a deliberate design constraint rather than a feature: the material these tools are useful on — a real enrolment credential, a chain from a test PKI, an APDU trace from a provisioning line — is exactly the material an engineer should not paste into someone else's web service.
It also removes a class of question from procurement. There is no data-processing agreement to negotiate over a parser that never receives the data.
The practical consequence is that the tools are structural rather than cryptographic. The chain validator, for example, computes HashedId8 linkage with WebCrypto and checks validity windows and signature schemes, but does not verify signatures against a trust anchor — that requires the trust material, which is precisely what does not belong in a browser tab. It is a debugging aid, not a compliance test. Conformance testing is a laboratory process.
Three situations and the tool that shortens them.
| Situation | Reach for |
|---|---|
| A certificate came back from an authority and the device rejects it | The IEEE 1609.2 parser, to see which field differs from what your code expects. Most early enrolment failures are profile mismatches, not cryptographic failures. |
| The chain resolves in your code but not on the device | The chain validator, to confirm the HashedId8 of each issuer actually matches the certificate it names. |
| The secure element returns a status word you have not seen | The APDU and TLV parsers, plus the GlobalPlatform status reference — the provisioning side of the same programme. |