Documentation embedded in this build.

Claiming a credential from AuthboxVault

Some people cannot run authboxclient or openssl — a locked-down workstation, a tablet, a browser and nothing else. If your deployment runs AuthboxVault with the courier surface enabled, an administrator can hand you a claim link instead, and you finish enrolment entirely in the browser.

This page is honest about the trade before it is convenient about the steps: on every other enrolment path, your private key is generated on your machine and never leaves it. On this one, the key is generated at the vault, sealed into an encrypted file, delivered to you once, and then destroyed at the vault. That brief existence as a transferable file is recorded permanently: this credential is courier-grade, and it can never claim to be hardware-held. For most people this trade is fine. If you can run the client instead, run the client — see Enrolling with AuthBox.

What you will need

• Your subject DN and invitation token together, from your administrator (their tooling prints both as a pair). The invitation is single-use, expires, and names your exact subject — it authorizes this one enrolment and nothing else, and the claim form needs the DN exactly as written.

Some deployments mail this instead of handing it over, and there are two shapes of that message. Either it carries the whole claim link and you need nothing else, or it carries the link and says explicitly that your token is not in it and names how it reaches you — a phone call from your sponsor, say. If a message tells you the token is coming another way, wait for that channel; there is nothing missing from the mail. - A delivery passphrase you choose, at least 12 characters. You will type it twice in your life: once on the claim page, once at import. It protects the file in between.

The claim, step by step

1. Open the claim link. The token and your subject name are pre-filled — check the subject matches exactly what you were invited as.
2. Choose your delivery passphrase and submit. The vault generates your key, enrols with your invitation, and the download starts: a .p12 file holding your new certificate and its key, encrypted with your passphrase.
3. Do not close the tab until the download finishes. If the download is lost — tab closed, network dropped — the certificate exists and your key does not. There is no retry and nothing to recover: tell your administrator, who revokes the certificate and issues you a fresh invitation.
4. Import the .p12 into your browser or system keychain. It asks for the passphrase; this is the second and last time you type it.
5. Verify the import worked: open the console. It should recognise you by name.
6. Delete the downloaded file. Your keychain holds the key now; the file on disk is a loose copy with no further purpose.

If the claim is refused

The claim page gives one answer for every refusal: a valid auto-issuing invitation for this subject is required. It does not say which part failed — an unknown token, a spent one, an expired one, and a subject mismatch all read the same, deliberately, so a guessed token learns nothing. Your administrator can read the exact reason in the audit records. The common causes: the invitation expired (they are short-lived on purpose), the subject you typed differs from the one invited, or the invitation was created without auto-issue — the courier refuses to hold your key while an approval queue drains, and the page will name the queued request an administrator needs to clean up.