OSINTverse

For trainers, CTFs, conferences, and communities

Certificates investigators can verify. A signed record, a public key, a page that says what still stands.

OSINT Certificates is the credential issuer built into OSINTverse. Every certificate is a canonical JSON record, hashed, signed with Ed25519, and published on a page with JSON and Markdown twins, so a hiring manager, a conference, or an agent can check it without trusting our HTML. Recipients decide whether the page shows their name, their handle, or both.

  • Free for issuers at launch
  • Ed25519 signatures, SHA-256 hashes, published keys
  • Pages are unlisted until the recipient says otherwise

New in November 2026. The first issuers are OSINTverse's own events; the counters appear once there is something to count.

Why an OSINT-specific issuer

Built for people who verify things for a living

Generic credentialing tools lead with a design editor and engagement tracking. OSINT Certificates leads with the record, because the people reading these pages are the ones who check sources.

  • Verification first

    Each certificate is a canonical JSON record, SHA-256 hashed and Ed25519 signed. The hash and a QR code sit on the PDF, the public keys are published, and the page has JSON and Markdown twins.

  • Handle-aware privacy

    Investigators are known by handles. A certificate can name a handle, a name, or both, and the recipient chooses what the public page shows within what the issuer allows. A withheld name cannot be confirmed by guessing: it is a salted commitment in the record.

  • Unlisted by default

    Verification pages are reachable by link only until the recipient opts into search engines. No tracking pixels in the email, no third-party scripts on the page, a view counter and nothing more.

  • Live status, honest history

    Revoked, expired, and superseded certificates keep their pages and say so at the top, with the date and the issuer's public reason when there is one. A corrected certificate links to its replacement.

  • Evidence and skills

    Types carry a link to the syllabus, scoreboard, or recording, per-recipient fields such as score, rank, or hours, and tags from an OSINT skill taxonomy (12 skills, from geolocation to breach data).

  • Issuer trust you can see

    Every page says whether OSINTverse has verified the issuer. Verification is a human review with a domain proof, and it unlocks bulk issuing. Suspended issuers stop issuing while their existing certificates keep their real status.

Verify it yourself

The page is a convenience. The record is the proof.

Anyone can check a certificate with curl and openssl, no account and no API key. Every verification page links to the signed JSON, the Markdown twin, and the public keys.

  1. 01

    Fetch the JSON twin of the verification page. It carries the signed record, the SHA-256 hash, the Ed25519 signature, and the key id.

  2. 02

    Serialise the record as canonical JSON (keys sorted at every level, no whitespace) and check that its SHA-256 matches the hash.

  3. 03

    Fetch the public key whose id matches from the keys endpoint and verify the signature over the same bytes.

  4. 04

    For a disclosed name or handle, recompute the salted commitment and compare it with the one inside the record.

  5. 05

    Replay the public transparency log up to the certificate's position and check that the chain hash matches; the signed head commits to the latest entry.

Fetch the signed record

curl -s https://osintverse.com/certificates/verify/OVC-XXXX-XXXX-XXXX.json

Public keys, past and present, at /api/certificates/keys. A rotated key never breaks an older signature.

Every certificate issued through OSINTverse is appended to a public hash chain in issue order: ids, issuers, hashes, and status, never recipients. A removed or altered certificate breaks the chain for everything after it.

Open the transparency log

The signature proves the record was issued through OSINTverse and has not changed. It does not vouch for the issuer unless the issuer is marked verified.

For issuers

A type, a list of recipients, a signed batch

Issuers are teams, so a course, CTF, or community keeps its issuer when people change. A team of one is fine.

  1. 01

    Create the issuer

    Name, logo, website, and a short description. Request verification with a domain proof when you are ready; it is a human review.

  2. 02

    Define a credential type

    Title, description, layout (landscape certificate, portrait certificate, square badge), one accent colour, up to 2 signatories, up to 6 per-recipient fields, skills, an evidence link, an optional validity period, and which display modes recipients may pick.

  3. 03

    Issue

    One form, a CSV with a validation preview (bad emails, duplicates, already issued), or the REST API. Each recipient gets one email with a claim link and the verification link. No open or click tracking.

  4. 04

    Keep it honest

    Resend the email, reissue after a typo (the old record is marked superseded and points at the new one), or revoke with a public or private reason. Every certificate has an event log.

Two trust levels

Unverified issuers can issue from day one: one certificate at a time, up to 25 a month, and the page says the issuer is not verified by OSINTverse.

Verified issuers get CSV batches of up to 500 recipients, up to 2000 certificates a month, and the Verified mark on every page.

Free for every issuer at launch: no card, no per-certificate fee. Caps, not invoices, keep the sending domain clean.

See the verified issuers

For recipients

Your name, your handle, your call

A certificate is verifiable the moment it is issued. Claiming it with the email it was sent to unlocks the privacy controls and puts it on your profile.

  • Choose what the page shows

    Name only, Handle only, name withheld, Name and handle: whichever the issuer allowed for that type. The signed record commits to both without revealing the withheld one.

  • Unlisted until you say otherwise

    Pages are reachable by link only. Turn on search-engine indexing per certificate when you want it found.

  • A profile that lists what you choose

    List a certificate on your public OSINTverse profile next to your socials. Nothing is listed until you tick the box, and your profile stays private until you list something.

  • Downloads and sharing

    PDF and PNG with the QR and hash printed on them, an Add to LinkedIn link that fills in the issuer, date, id, and URL, and a social card for X.

  • If you delete your account

    The certificate is unlinked from you, delisted, and hidden from search engines. The issuer keeps its record and the id stays verifiable, because a certificate revoked by deletion would misrepresent what the issuer awarded.

API and agents

Verify from anywhere, issue from your own systems

Trainers run their own sites and LMSs; verifiers increasingly run agents. Both get a plain interface.

  • Public verify endpoint

    GET the JSON twin of any verification page without a key. Rate-limited per IP, never includes the email, carries the record, hash, signature, and the steps to check them.

    GET /api/certificates/verify/{id}
  • MCP tool for agents

    OSINTverse MCP has a read-only verify_credential tool: pass a credential id, get the same public record back. Free, in sandbox and live mode alike.

    verify_credential { credential_id }
  • Issue over REST

    A team API key with Certificates access issues single or batch JSON, reads a certificate with its event log, lists what you issued, and revokes. Same caps as the console.

    POST /api/certificates/issue

Compared with a generic credentialing tool

Certifier and tools like it sell a designer. We sell a record.

Certifier is a capable, general-purpose credentialing service: a drag-and-drop designer, bulk sending, and engagement analytics, with a verification page as the proof. OSINT Certificates skips the designer and puts the proof first.

Generic credentialing software compared with OSINT Certificates
Generic credentialing SaaSOSINT Certificates
Proof of authenticityA verification page you trust because the vendor hosts it.A signed record, a published public key, and a JSON twin you can check yourself.
Recipient identityThe name the issuer typed.Name, handle, or both, chosen by the recipient; a withheld name is a salted commitment.
Default visibilityIndexed, with engagement tracking.Unlisted until the recipient opts in; no pixels, no third-party scripts.
DesignA drag-and-drop designer and template marketplace.3 fixed layouts with your logo, accent colour, and signatories.
AudienceAny organisation that issues certificates.OSINT trainers, CTFs, conferences, communities, and the investigators they certify.
Where it livesIts own site.Next to the recipient's profile, the OSINT Collective, and the rest of OSINTverse.

If you need a custom-designed certificate, white-label hosting, or LMS integrations today, a generic tool is the better fit. Those are deliberate skips, not gaps we hide.

FAQ

Questions issuers and recipients ask

What does OSINT Certificates cost?

Nothing at launch, for every issuer. There is no card and no per-certificate fee. Caps by trust level keep the sending domain clean; if pricing changes later, it will be computed from the same constants and shown before anyone issues.

Who can issue?

Any team on OSINTverse. A solo trainer creates a team of one. Team owners and admins manage the issuer and verification; owners, admins, members, and analysts issue, resend, reissue, and revoke.

What does issuer verification involve?

You submit a proof that you control the issuer's domain (a page, a DNS record, or an email on the domain) and a person at OSINTverse reviews it. Approval unlocks bulk issuing and the Verified mark; the page says when an issuer is not verified.

How does someone verify a certificate without trusting the page?

They fetch the JSON twin, serialise the record as canonical JSON, check its SHA-256 against the hash, and verify the Ed25519 signature with the published key whose id matches. The docs include a worked example with curl and openssl.

Can a certificate show a handle instead of a name?

Yes, when the issuer allowed handle mode for that type and the recipient has a handle on record. The page then shows the handle with the name withheld, while the signed record still commits to the name through a salted hash, so nobody can confirm a guessed name.

Are verification pages indexed by search engines?

Not by default. Each page is reachable by link only until the recipient turns on indexing for it. Issuers cannot override that choice.

What happens when the issuer makes a mistake?

The issuer reissues: a new signed record is created and the old one is marked superseded, pointing at the replacement. Signed records are never edited in place. A certificate that should not stand is revoked, with a reason the issuer can make public or keep private.

Can I issue from my own LMS or website?

Yes. Create a team API key with Certificates access and call the REST API to issue single or batch JSON, read, list, and revoke. CSV import covers the rest. Zapier and LMS plugins are not planned for now.

Does OSINTverse vouch for the issuer?

The signature proves the record was issued through OSINTverse and has not changed. Only the Verified mark says OSINTverse checked who the issuer is. Both facts are on every page and in the JSON.

Is this an Open Badges or Verifiable Credentials implementation?

Every valid certificate also exports as an Open Badges 3.0 credential: a W3C Verifiable Credential in JSON-LD with a Data Integrity proof (eddsa-jcs-2022) signed by the same key, published as a did:web document. The export is built from the signed record on request, so nothing is reissued, and the recipient appears only as a hashed identity for the fields they chose to show.

Issue your first certificate in an afternoon

Create a team, set up the issuer, define a type, and send one certificate to yourself. Verify it with curl before you tell anyone.

Already holding one? Open your certificates to choose what the public page shows.