808bits

CKR_SLOT_ID_INVALID

PKCS#11 return value · 0x00000003 · decimal 3
hex 0x00000003 decimal 3 name CKR_SLOT_ID_INVALID

Nothing in the specification promises that slot numbers stay the same across restarts, across machines, or across a configuration change, and on several vendors they do not. Code written against a number that was correct on a developer's machine is the ordinary way this appears, and it appears at deployment rather than in testing.

What the token is reporting

There is no slot with that identifier in this library instance. Note that identifier, not index: slot identifiers are opaque values the library chooses, and they are not required to start at zero or to be contiguous.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

The slot number was hard-coded

Slot zero exists on most development setups and on plenty of production ones it does not, or it belongs to something else. Some vendors derive slot identifiers from serial numbers, so they are large and look nothing like an index.

Check it: Enumerate the slots and print their identifiers alongside their token labels. If the identifiers are not small integers, any code treating them as indexes is wrong everywhere, not only here.

Fix: Find the slot by token label at startup. It is a few extra lines and it removes an entire class of deployment failure.

The enumeration changed

Adding a reader, removing a token, or reconfiguring an appliance can renumber everything. The application is not wrong so much as out of date, and it will be out of date again after the next change.

Check it: Compare the current enumeration against whatever the application was configured with. If they differ, that is the whole story.

Asking only for slots with tokens, then using the wrong list

The enumeration call can return all slots or only those with a token present, and the two lists differ. An identifier taken from one and used against an expectation set by the other will not line up.

Check it: Check which form of the call produced the identifier you are using, and make sure the same form is used consistently.

Which calls return it

C_OpenSession, C_GetSlotInfo, C_GetTokenInfo, C_GetMechanismList

What it is not

It is not a missing token. A slot that exists but is empty is a different condition with its own code, and it means the slot number was right.

Often confused with

  • CKR_TOKEN_NOT_PRESENT: The slot is real and empty. That is a better outcome, because it means your slot identifier was correct.

By library

SoftHSMv2

The slot number changes the moment a token is initialised. [SlotManage r](https://github.com/softhsm/SoftHSMv2/blob/884cb38f3d2012a0447bd5f50 dbd29c429987c41/src/lib/slot_mgr/SlotManager.cpp#L45-L78) derives each token’s slot from the last eight hex digits of its serial, so slot 0 holds a token only until softhsm2-util --init-token moves it to a number like 1613085303 and renumbers the empty slot to 1. Every CI run that creates a fresh token gets a fresh number. Address the token by label or serial instead.

Sources

Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.