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 163 of 221; 24 results per page.
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.
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.
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.
Tiny multi-language SAMPLE monorepo ZIP (web/api/util/scripts) for unpack-then-lint and monorepo tooling.
The DER OCSPRequest a client sends when checking the reference leaf, with the SHA-1 CertID that RFC 6960 mandates and no nonce extension. POST it at a stub responder to exercise request parsing without a live CA.
A successful OCSP response asserting status good for the reference leaf, signed directly by the SAMPLE issuing CA. Pair it with the request beside it to stub a responder end to end.
The OCSP counterpart of the CRL entry: status revoked for the revoked SAMPLE leaf, with the same 2026-03-01 revocation time and keyCompromise reason. Use both against the same certificate to check that CRL and OCSP paths agree.
The minimal unsuccessful OCSP response: responseStatus unauthorized and no responseBytes at all, which is what a responder returns for a certificate it does not serve. A handful of bytes that regularly breaks clients expecting a signed body.
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.
