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 3 of 6; 24 results per page.
A mutual-TLS client certificate: EC P-256 subject key, clientAuth EKU only, and an OU naming the fictional access group. Present it to an mTLS endpoint to test client-certificate parsing and EKU enforcement.
A code-signing certificate (codeSigning EKU, digitalSignature only) issued by the SAMPLE intermediate. It signs nothing real — it exists so signature-verification tooling has an EKU-correct certificate to reason about.
A CSR with nothing but a Common Name and no requested extensions — the output of the shortest possible openssl req invocation. Intake code that assumes an extensionRequest attribute exists breaks on it.
An Ed25519 certificate request. Its signature algorithm identifier carries no separate hash OID, which is exactly the field that trips older CSR parsers written around RSA and ECDSA.
An intentionally corrupt PKCS#10 request: the PEM armour is intact but four illegal characters have been substituted into the Base64 body, so decoding fails part-way. It exists to check that a CSR intake path reports a parse error instead of a stack trace or a partially populated record.
The CSR shape a modern CA expects: full subject DN, a requested subjectAltName extension, and a self-signature proving possession of the RSA key. Everything a CA intake form needs to parse.
A wildcard certificate request covering *.csr.pki.sample.example plus the apex. CA policy engines usually treat wildcards specially, so this is the input that exercises that branch.
The exact bytes covered by the detached PKCS#7 signature shipped beside it. LF line endings are part of the contract — rewriting the file with CRLF is the fastest way to watch a signature check fail for a reason nobody suspects.
The P-256 key behind the EC leaf certificate, in PKCS#8. Its scalar is derived deterministically from a fixed label so the whole wave reproduces byte for byte.
The same P-256 scalar in the SEC 1 container (BEGIN EC PRIVATE KEY), which names the curve inline instead of through a PKCS#8 algorithm identifier. Some deployment tools accept only one of the two.
The P-256 public key in SubjectPublicKeyInfo form, carrying the named-curve OID and an uncompressed point. It matches the EC leaf certificate and the EC entry in the p7 JWK set.
The Ed25519 key behind the Ed25519 leaf and the EdDSA JWTs, in PKCS#8. RFC 8410 keys have no traditional-OpenSSL container at all, which is why only one serialisation ships.
Binary DER encoding of the SAMPLE intermediate CA certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
The issuing CA that signs every leaf in this wave, itself signed by the SAMPLE root and constrained with pathLenConstraint:0 so it cannot mint further CAs. Use it to test intermediate handling and path-length enforcement.
A single P-256 public JWK. Its x and y are fixed 32-byte base64url values, left-padded when a coordinate happens to be short — the padding rule that libraries stripping leading zeroes get wrong.
An OKP-type JWK holding the Ed25519 key pair as raw 32-byte x and d values. OKP is the newest JWK key type and the one older JOSE libraries reject outright.
The full RSA private key as a JWK, including the CRT parameters p, q, dp, dq and qi. It is the input for testing JWK-to-PEM conversion, where dropping the CRT values quietly costs a large amount of signing performance.
The symmetric HMAC secret used by this wave's HS256 tokens, expressed as an oct JWK. The secret is printed in the specs on purpose so a verifier can be wired up without guessing.
Two keys of different types published under the same kid — what a botched key rotation leaves behind. A resolver that returns the first match silently verifies against the wrong key type instead of reporting the ambiguity.
A JWK Set whose keys carry no kid at all, which RFC 7517 permits. Verifiers must then fall back to trying candidates by algorithm, and the ones that index the set by kid alone find nothing.
A three-key JWK Set publishing the public halves of this wave's RSA, P-256, and Ed25519 keys, each with a distinct kid. It is the resolver input for every p7 JWT, so kid selection can be tested against a set that really has more than one candidate.
A JWK carrying the full x5c certificate chain and an x5t#S256 thumbprint alongside the raw n/e values. The x5c array is standard Base64 while every other JWK field is base64url — a real and frequently mis-implemented detail.
The single-signature flattened JSON form of the exact same RS256 token shipped in compact serialization. Both encodings must verify to the identical payload, which is the round-trip this pair is for.
One payload carrying two independent signatures — RS256 and EdDSA — in the General JSON serialization that the compact form cannot express. Multi-signature handling is the part of RFC 7515 most libraries never implemented.
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.
