Self-signed X.509 certificates (PEM, CRT, DER), a CSR, RSA and Ed25519 keys, an SSH public key, a PKCS#12 bundle, and an htpasswd file — all published sample-only material, for testing certificate parsers, TLS tooling, keystore importers, and PEM/DER decoders.
A self-signed X.509 v3 certificate in PEM (Base64) encoding with a SAN and key-usage extensions — published sample material for testing certificate and TLS parsers. Not a real identity.
The same self-signed certificate under the conventional .crt extension (PEM-encoded) — for testing trust-store importers and tools that key off the .crt extension. Sample only.
The binary DER encoding of the same certificate — for testing ASN.1/DER parsers, Java keystores, and DER-to-PEM converters. Published sample certificate, not a real identity.
A PKCS#10 certificate signing request (PEM) with the subject and SAN, self-signed by the RSA key to prove key possession — for testing CSR parsers and certificate-authority intake flows.
A 2048-bit RSA private key in unencrypted PKCS#8 PEM — a deliberately PUBLISHED, sample-only key for testing PEM key parsers and PKCS#8 decoders. Never use it for anything real.
An Ed25519 private key in PKCS#8 PEM, derived from a fixed seed — a published, sample-only modern elliptic-curve key for testing PEM parsers and Ed25519 tooling. Never use it for real.
An OpenSSH-format Ed25519 public key (the shareable half of the key pair) — a single line of algorithm, Base64 key blob, and comment, for testing SSH public-key parsers and authorized_keys tooling.
A PKCS#12 (.p12/PFX) bundle packaging the sample RSA key and certificate together, protected with the sample password 'novus-sample' — for testing keystore importers and PKCS#12 parsers. (The PKCS#12 MAC salt is random, so this file is intentionally not byte-stable.)
An Apache/nginx .htpasswd file with two users hashed using the {SHA} scheme (Base64 SHA-1) — the sample passwords are documented in the file, for testing Basic-Auth credential parsers and hash identification.
Self-signed X.509 SAMPLE certificate in PEM under /files/security/ — published sample material for TLS and PEM parsers.
Same SAMPLE certificate as .crt (PEM bytes) for tools that expect the CRT extension.
DER-encoded twin of the Wave G SAMPLE certificate for binary X.509 decoders.
Two-PEM-block SAMPLE chain file for multi-cert parsers and bundle importers.
PKCS#10 certificate signing request SAMPLE for CSR parsers and CA tooling smoke tests.
Published SAMPLE RSA-2048 private key (PKCS#8 PEM). Never use for a real identity.
Deterministic SAMPLE Ed25519 private key for SSH/TLS tooling tests.
OpenSSH-format SAMPLE Ed25519 public key for authorized_keys and SSH parsers.
SAMPLE PKCS#12 keystore (password `novus-sample-wg`) for keystore importer tests. Not byte-stable.
Password-encrypted SAMPLE PKCS#8 private key (password printed in specs) for decrypt-import tests.
SAMPLE SSH known_hosts with fictional hostnames for known_hosts parsers and StrictHostKeyChecking tests.
Single-entry SAMPLE authorized_keys file for SSH access-control parsers.
SAMPLE htpasswd with a bcrypt hash line for Basic-auth file parsers.
SAMPLE htpasswd using Apache APR1 MD5-style hash for legacy Basic-auth tests.
Multi-user SAMPLE htpasswd mixing bcrypt, APR1, and {SHA} lines for algorithm-detection tests.
SAMPLE OpenSSH client config stanza for SSH config parsers.
ASCII-armored SAMPLE-shaped PGP public key placeholder for armor detectors (not a cryptographically valid key).
SAMPLE CRL metadata JSON (no binary CRL) for revocation-list UI and loader tests.
SAMPLE HTTP security header fixture (strict-transport-security) for scanner regression.
SAMPLE HTTP security header fixture (content-security-policy-report) for scanner regression.
SAMPLE HTTP security header fixture (permissions-policy) for scanner regression.
SAMPLE HTTP security header fixture (cross-origin-opener) for scanner regression.
SAMPLE HTTP security header fixture (cross-origin-embedder) for scanner regression.
SAMPLE HTTP security header fixture (cross-origin-resource) for scanner regression.
SAMPLE HTTP security header fixture (referrer-policy-strict) for scanner regression.
SAMPLE HTTP security header fixture (x-content-type-options) for scanner regression.
SAMPLE HTTP security header fixture (x-frame-options-deny) for scanner regression.
SAMPLE HTTP security header fixture (expect-ct-legacy) for scanner regression.
The self-signed root of the Novus Examples SAMPLE certificate hierarchy (RSA-4096, CA:TRUE, no path-length limit). Install it as the only trust anchor to make the rest of this wave's chains verifiable in a sandbox. Fictional issuer — never a real identity.
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.
Binary DER encoding of the SAMPLE root CA certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
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.
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 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 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.
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 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.
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.
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.
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 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.
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 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.
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.
An S/MIME-shaped certificate whose SAN is an rfc822Name rather than a DNS name, with the emailProtection EKU and a non-repudiation key usage. Useful for testing address extraction from certificates.
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.
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.
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.
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.
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 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.
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.
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 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.
A degenerate (certificates-only) PKCS#7 structure holding all three SAMPLE certificates under BEGIN PKCS7 armour — the payload Windows and Java tools distribute as a .p7b. It carries no private key and no signature over any content.
Binary DER form of the same three-certificate PKCS#7 bundle, the encoding a .p7b download actually uses. Use it to test importers that never see the PEM armour.
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.
A detached PKCS#7 SignedData over signed-payload.txt, built without signed attributes so the bytes are reproducible. The content is not embedded, so verification needs both files — exactly the failure mode people hit with .p7s email attachments.
A password-protected PKCS#12 keystore holding the SAMPLE leaf key together with its whole issuing chain, so one import gives a client both an identity and its anchors. The password `novus-p7-sample-p12` is published on purpose; nothing inside is a real credential.
The same leaf key and certificate in a PKCS#12 file with no password and no encryption. Several importers refuse an empty password, prompt anyway, or treat it as the literal empty string, so this is the fixture that finds out which.
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 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.
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.
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 SAMPLE leaf's RSA-2048 key in unencrypted PKCS#8 (BEGIN PRIVATE KEY) — the modern default and the pair to the PKCS#1 twin beside it. It is deliberately published; treat it as public.
The identical key material wrapped in the legacy PKCS#1 container (BEGIN RSA PRIVATE KEY), which omits the algorithm OID that PKCS#8 carries. Diff it against its PKCS#8 twin to see exactly what a container migration changes.
The SAMPLE leaf key under PKCS#8 password encryption (BEGIN ENCRYPTED PRIVATE KEY, PBES2), password `novus-p7-sample-pkcs8`. Encryption metadata lives inside the ASN.1 here, not in PEM headers — the opposite of the PKCS#1 twin.
The legacy encrypted-key layout: PKCS#1 body plus `Proc-Type: 4,ENCRYPTED` and `DEK-Info` PEM headers carrying the cipher and IV, password `novus-p7-sample-pkcs1`. Parsers that strip PEM headers before decoding silently lose the IV and fail here.
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 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.
The SAMPLE leaf's public key as a bare SubjectPublicKeyInfo (BEGIN PUBLIC KEY) — the form JWT verifiers and most language runtimes expect when you hand them a key rather than a certificate.
The same modulus and exponent in the raw PKCS#1 RSAPublicKey container, without the algorithm-identifier wrapper. Libraries routinely accept one armour and reject the other, so the pair is the test.
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 SAMPLE leaf's RSA key in single-line OpenSSH format with a comment — the same key material as the PEM public keys, wrapped the way authorized_keys wants it. Handy for checking that a fingerprint tool agrees across encodings.
The P-256 public key in OpenSSH form, whose blob names the curve twice — once in the key type and once inside the payload. Parsers that read only one of the two mis-handle mismatched keys.
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.
A Sigstore bundle in the shape verifiers read: a SAMPLE certificate, a transparency-log entry with an inclusion proof and checkpoint, and the DSSE envelope carrying the provenance. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
An ASCII-armored detached signature block of the shape that accompanies a SHA256SUMS file. It is a SAMPLE placeholder, not a valid OpenPGP signature — armor detectors will find it, verifiers must reject it. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
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.
