Where is the SPIFFE ID stored in a certificate?

In the URI entry of the Subject Alternative Name extension. There is exactly one per SVID, and Common Name is not used for identity.

Why are SVIDs so short-lived?

Short lifetimes mean a stolen credential is useful for minutes rather than months, and they force rotation to actually work rather than being an untested emergency path.

The other SPIFFE credential form — a JWT whose sub claim is the SPIFFE ID, used where mTLS isn't available. Decode it with the JWT decoder.

SPIFFE Certificate Decoder

Extract SPIFFE IDs and SVID details from workload identity certificates.

on the roadmapSecurity, PKI & Cryptofree · no sign-up

This bench is being wired up

The spiffe-decoder decoder is on the roadmap. The heavier binary and cryptographic parsers ship after the core text and token decoders — all of which are already live and working.

Browse the live decoders

Input is processed on your device. Nothing you paste is sent anywhere.

What is the SPIFFE Certificate Decoder?

A SPIFFE decoder reads an X.509-SVID certificate and extracts the SPIFFE ID from its URI Subject Alternative Name, showing the trust domain and workload path that identify a service in a zero-trust mesh.

SPIFFE (Secure Production Identity Framework For Everyone) gives every workload a cryptographic identity instead of a shared secret. That identity is a URI of the form spiffe://trust-domain/path, and in an X.509-SVID it lives in the URI Subject Alternative Name — not in the Common Name, which SPIFFE deliberately leaves unconstrained.

The other distinctive property of an SVID is its lifetime. Where a web certificate lasts months, an SVID typically lasts minutes to hours, rotated automatically by SPIRE or by a service mesh like Istio. When mTLS between two services starts failing, the answer is usually visible in the SVID: the wrong trust domain, an unexpected workload path, or a certificate that outlived its rotation window.