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 161 of 221; 24 results per page.
Base B with 2% salt-and-pepper noise (seed 77002). A direct fixture for testing median and morphological denoisers against the clean reference.
Base A with 5% salt-and-pepper noise (seed 42005). A direct fixture for testing median and morphological denoisers against the clean reference.
Base B with 5% salt-and-pepper noise (seed 77005). A direct fixture for testing median and morphological denoisers against the clean reference.
Six alignments against a synthetic contig with a full @HD/@SQ/@RG/@PG header, both strands via the reverse flag, and CIGAR strings covering match, soft clip, insertion and deletion. Reference span and query length come apart in three of the records, which is where CIGAR arithmetic gets tested.
Each alignment's CIGAR decomposed into how many query bases and how many reference bases it consumes, with the resulting 1-based reference end. The three records where those numbers differ are the whole reason CIGAR arithmetic is worth testing.
Sample App .env: small deterministic fixture for parsers and the in-browser editor.
The two CA certificates concatenated in trust-store order, the shape a `--cafile` or `ca-bundle.crt` argument expects. Point a client at this and every other valid p7 leaf becomes verifiable.
Binary DER twin of the SAMPLE CRL: the exact encoding a CRL distribution point serves over HTTP. Use it to test binary CRL fetching and caching paths that never see PEM armour.
The issuing CA's revocation list, PEM-armoured, naming the revoked SAMPLE leaf (keyCompromise) plus a second serial with no matching certificate file, because a real CRL lists serials, not certificates. Signed by the same intermediate that issued them.
A correctly signed CRL with an absent revokedCertificates field: what a CA publishes when it has revoked nothing. Parsers that assume the list is always present tend to fault here rather than report zero entries.
A validly signed CRL whose nextUpdate passed in 2020. Whether a client hard-fails, soft-fails, or silently trusts stale revocation data is a real policy decision, and this is the fixture that reveals which one it made.
The bundle a TLS server actually presents: leaf first, then the issuing CA, with the root deliberately omitted because clients must already trust it. This is the correct-by-construction reference for the chain-order fixtures beside it.
The same chain with the self-signed root appended. Sending the root is legal and common, merely wasteful, so a verifier must ignore the extra anchor rather than treat it as an error.
Leaf plus root with the issuing CA left out: the single most common TLS misconfiguration, and the one that works in browsers with a cached intermediate and fails everywhere else. Use it to prove a client does not silently paper over the gap.
The leaf and intermediate concatenated backwards. Strict servers reject the file outright while tolerant path builders reorder it silently, so it cleanly separates the two behaviours.
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.
Sample Dockerfile: small deterministic fixture for parsers and the in-browser editor.
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.
