Signing/Verifying on Windows using TPM2 and TBS

[samthesloth]

Hello!

I have been having issues with using a few commands with the provider on Windows. I think the issue is with using ContextSave/Load on Windows as streaming to the TPM might be blocked by the OS. For the simple CSR test/example, I have been getting the following error when issuing the certificate from the TPM-based CA:

ERROR:esys:api\Esys_ContextSave.c:256:Esys_ContextSave_Finish() Received a non-TPM Error ERROR:esys:api\Esys_ContextSave.c:97:Esys_ContextSave() Esys Finish ErrorCode (0x80280400) ERROR:esys:esys_iutil.c:1253:iesys_check_sequence_async() Esys called in bad sequence. ERROR:esys:api\Esys_FlushContext.c:69:Esys_FlushContext() Error in async function ErrorCode (0x00070007) Certificate request self-signature did not match the contents 2CCB0000:error:40800013:tpm2:tpm2_hash_sequence_dup:cannot duplicate context:src\tpm2-provider-digest.c:49:-2144861184 2CCB0000:error:06880006:asn1 encoding routines:ASN1_item_verify_ctx:EVP lib:crypto\asn1\a_verify.c:217: RSA FREE ERROR:esys:esys_iutil.c:1253:iesys_check_sequence_async() Esys called in bad sequence. ERROR:esys:api\Esys_FlushContext.c:69:Esys_FlushContext() Error in async function ErrorCode (0x00070007)

I am curious if Windows is indeed blocking this or if it is an issue with how I installed/loaded the provider. If the former, could I simply modify some of the provider source code to "skip" this code or fix it for the Windows use-case?

EDIT: So, I have possibly "fixed" it. When running the command, taking out -propquery "?provider=tpm2" seems to make the command work, including having the TPM2 key still do the signature. Could someone help explain why this is the case? Is this causing another problem "under the hood?" Sorry for my possible ignorance, and thank you so, so much for your help!

[cr-AaronMontsarj]

I've tested on Windows 11 with tpm2-openssl 1.1.0 and OpenSSL 3.0.13, and can confirm your workaround works. However, I found that omitting -propquery '?provider=tpm2' alone is not sufficient for some operations.

The Problem

For example, signing a CSR with a TPM-backed CA key:

# This fails even WITHOUT -propquery:
openssl x509 -provider tpm2 -provider default -req -in client.csr -CA ca.crt -CAkey ca_key.pem -out client.crt

Produces this error:

ERROR:esys:api\Esys_ContextSave.c:239:Esys_ContextSave_Finish() Received a non-TPM Error
ERROR:esys:api\Esys_ContextSave.c:90:Esys_ContextSave() Esys Finish ErrorCode (0x80280400)
...
00790000:error:40800013:tpm2::cannot duplicate context::-1:-2144861184

The Solution: Provider Order

The order of providers matters. When tpm2 is listed first, OpenSSL uses it for digest/hash operations, which triggers the Esys_ContextSave error on Windows TBS.

The fix is to load default provider first:

# This works - default provider FIRST:
openssl x509 -provider default -provider tpm2 -req -in client.csr -CA ca.crt -CAkey ca_key.pem -out client.crt

With default first, OpenSSL uses it for digest operations while still using tpm2 for key operations (because the key is TPM-backed).

Exception: TPM Key Generation

For generating TPM private keys, -provider tpm2 alone (or first) works fine:

openssl genpkey -provider tpm2 -algorithm RSA -pkeyopt bits:2048 -out key.pem

This is because key generation doesn't involve the digest operations that trigger Esys_ContextSave.

For C++ / Programmatic Use

// Load default FIRST, then tpm2
OSSL_PROVIDER_load(nullptr, "default");
OSSL_PROVIDER_load(nullptr, "tpm2");

// For key generation - explicitly request tpm2 provider
EVP_PKEY_CTX* ctx = EVP_PKEY_CTX_new_from_name(nullptr, "RSA", "provider=tpm2");

// For signing - just use the TPM key, OpenSSL routes correctly
X509_sign(cert, tpm_key, EVP_sha256());

Pitfall: In-Memory Verification

Even with correct provider order, verifying a certificate using an in-memory TPM-backed EVP_PKEY can still fail:

X509_verify(cert, tpm_key);  // May fail with Esys_ContextSave error

Workaround: extract the public key to a regular EVP_PKEY first using i2d_PUBKEY/d2i_PUBKEY.