Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 4 of 6; 24 results per page.
An unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.
The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.
The EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.
An EdDSA (Ed25519) token with a fixed 64-byte signature and the same claim set as the RS256 reference. EdDSA signing is deterministic, so this token is reproducible in a way an ES256 one could never be.
A symmetric HS256 token whose secret is printed in the specs and shipped as an oct JWK, so a verifier can be stood up without any key exchange. It shares its claim set with the RS256 reference token.
The valid RS256 token with the last bit of its signature flipped. Header and payload are byte-identical to the valid twin, so any difference in outcome is entirely down to signature verification.
A correctly signed RS256 token whose exp passed on 2020-01-01. The signature still verifies, so it isolates expiry handling from every other check — including the libraries that validate the signature and then forget to look at exp.
A valid signature over a claim set whose nbf is 2035. Many verifiers check exp diligently and skip nbf entirely, so this is the token that finds out.
A perfectly well-formed RS256 signature made with the SAMPLE root key while the kid header still names the leaf key. Verifiers that trust the kid without checking the signature against that exact key accept it.
The reference token for this wave: RS256, signed by the SAMPLE leaf key, with iss, aud, iat, nbf, exp and jti all present and an expiry in 2036. Every other JWT here is a deliberate deviation from it.
A genuinely valid RS256 signature whose kid names a key that has been rotated out of the JWK set. The right behaviour is a clean key-not-found error, not a silent fallback to whichever key happens to be first.
The elliptic-curve twin of the reference leaf: identical subject, SANs, EKU and issuer, but a P-256 subject public key instead of RSA-2048. Diff the two to isolate exactly what changes when a deployment migrates key types.
The third key-type variant of the reference leaf, carrying an Ed25519 subject public key. Older TLS stacks and keystores reject id-Ed25519 outright, which makes this a compact compatibility probe.
A correctly signed leaf whose notAfter fell in the past (2020). The only thing wrong with it is the clock, which makes it the clean way to assert that an expiry error is reported as expiry and not as a signature failure.
A leaf whose SAN carries both a DNS name and an iPAddress entry (192.0.2.10, from the RFC 5737 documentation range). Connecting by literal IP must match the iPAddress entry, never the DNS one.
A pre-RFC 6125-style certificate carrying only a Common Name and no subjectAltName extension. Every current browser and most TLS libraries reject it outright, which makes it a precise legacy-compatibility probe.
The mirror of the expired leaf: identical in every respect except that notBefore is 2035, so it is rejected from the other side of the validity window. Pairs with it to prove a verifier distinguishes the two clock errors.
A leaf that is valid in every structural respect and revoked in the matching CRL and OCSP response shipped alongside it. It is the fixture that proves a client actually performs revocation checking rather than stopping at path building.
The reference end-entity certificate for this wave: RSA-2048 subject key, two DNS SANs, serverAuth/clientAuth EKU, and AIA/CRL pointers to the fictional SAMPLE responder. Everything else in the p7 PKI is a deviation from this one.
The certificate's CN is app.pki.sample.example but its only SAN is different.pki.sample.example. RFC 6125 clients must ignore the CN entirely, so this separates modern verifiers from ones still falling back to Common Name.
An end-entity certificate that signs itself and chains to nothing — the shape a development server produces when nobody ran a CA. It is internally consistent, so the only defect a verifier can find is the missing trust anchor.
A wildcard certificate covering *.wild.pki.sample.example plus the bare apex. Use it to check that a matcher accepts exactly one label and refuses to stretch the wildcard across a dot.
A valid, correctly chained certificate for the wrong host: both CN and SAN say wrong-host.pki.sample.example. Serve it for leaf.pki.sample.example to exercise the hostname-verification path on its own.
Binary DER encoding of the SAMPLE leaf certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
