808bits

CKR_TEMPLATE_INCONSISTENT

PKCS#11 return value · 0x000000D1 · decimal 209
hex 0x000000D1 decimal 209 name CKR_TEMPLATE_INCONSISTENT

Templates fail in two ways and this is the harder one to see, because nothing in the template is wrong on its own. The token has rules about which attributes can coexist, most of them there to stop key material escaping, and a combination that violates one of those rules is refused as a whole. The error names no attribute, so the work is in knowing which pairs conflict.

What the token is reporting

Every attribute you supplied is recognised and individually acceptable. The combination is not, either because the specification forbids it, because the key type does not support it, or because the token’s policy will not allow that pairing.

Likely causes

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

Extractable and sensitive, pulling in opposite directions

These two attributes are the heart of what an HSM is for, and tokens are opinionated about them. A key that is sensitive and also marked extractable is exactly the combination a hardened policy exists to prevent, and many tokens refuse it outright rather than allowing it and hoping.

Check it: Remove the extractable attribute and retry. If the template is accepted, the conflict was there, and the real question becomes why the key needed to leave the token.

Attributes that do not apply to that key type

A template carried over from one algorithm to another often brings attributes the new key type does not accept. Elliptic curve parameters on a symmetric key, or a modulus length on a curve key, are the usual shape of this.

Check it: Strip the template down to the minimum for the key type and add attributes back one at a time. The one that reintroduces the failure is the answer, and this is faster than reasoning about it.

A token policy that forbids the combination

Appliances can be configured to require or forbid particular attributes on every key. A template that works on a development token then fails on a hardened one, with no change to the code.

Check it: Compare against a token with a different policy. If the same template succeeds elsewhere, the policy is the constraint rather than the template.

A default the token applies that conflicts with what you set

Attributes you leave out are not absent, they take a default, and a default can conflict with something you did set. That makes the offending pair invisible in the template you wrote.

Check it: Create the simplest key of that type that the token accepts and read back all its attributes. That shows you the defaults you have been arguing with.

Which calls return it

C_CreateObject, C_GenerateKey, C_GenerateKeyPair, C_UnwrapKey, C_DeriveKey

What it is not

It is not an incomplete template. If something required were missing the token would say so with a different code, which is a more useful error because it points at what is absent rather than at a contradiction.

Often confused with

  • CKR_TEMPLATE_INCOMPLETE: Something mandatory is missing rather than in conflict. Easier to fix, and the token is more specific about it.
  • CKR_ATTRIBUTE_VALUE_INVALID: One attribute is wrong on its own. If you can find a single attribute at fault, this is not the code you should be reading.

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.