SAMPLE OCSP Response — Unauthorized
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.
| Field | Value |
|---|---|
| Type | OCSP response (DER, RFC 6960) |
| Response status | unauthorized (6) |
| Signed | no — unsuccessful responses carry no responseBytes |
| Bytes | 5 |
Specifications
- Response Status
- unauthorized (6)
- Signed
- false
- Bytes
- 5
- Sample Only
- true
- Seed
- 70117
Testing contract
Expected to fail- Scenario
- Feed this response to the OCSP client under test as the answer to a status query.
- Expected result
- The client reports responseStatus unauthorized and does not attempt to parse or verify a missing signed body.
What is a .der file?
DER (Distinguished Encoding Rules) is the binary encoding of an X.509 certificate (or other ASN.1 structure) — the same data a PEM file Base64-wraps, without the text armour. A .der certificate is compact and byte-exact, common in Java keystores and Windows tooling.
How to use this file
Use an example .der certificate to test binary X.509 parsers, ASN.1 decoders, and DER-to-PEM converters, or to confirm a tool reads raw certificate bytes. Published sample certificate, not a real identity.
How to use this file for testing
“SAMPLE OCSP Response — Unauthorized” is a deterministic Novus Examples fixture for Certificate & key testing, Error handling. 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.
Documented properties for this file: seed 70117. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
This is published, SAMPLE-only security material — never a real secret. Point certificate, key, or token parsers at it, test PEM/DER decoding and PKCS handling, and confirm your tooling reads the documented fields; any sample password is printed on this page.
This is a published, sample-only certificate/key. Parse it, verify the chain or signature, and test PEM↔DER conversion — never deploy it anywhere real.
Related files
- pemSAMPLE Certificate Revocation List — EmptyA 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.
- pemSAMPLE Certificate Revocation List — StaleA 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.
- csrSAMPLE CSR — Intentionally Corrupt Base64An 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.
- pemSAMPLE Leaf Certificate — ExpiredA 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.
- pemSAMPLE Leaf Certificate — No SAN ExtensionA 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.
- pemSAMPLE Leaf Certificate — Not Yet ValidThe 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.
Generated by generation/security_p7.py. Free for any use, no attribution required — license.