CryptAcquireContext returns NTE_BAD_KEY_STATE?

[Michael Pflug]

I have one certain Win2003-Server (so far), where a call to

CryptAcquireContext

will always result in NTE_BAD_KEY_STATE / 0x8009000B (note: _not_
NTE_BAD_KEYSET, which
would be a common result).

The MSDN-Help doesn't even mention the possibility of this result for
CryptAcquireContext.

To make sure, I made a small program, that does nothing else but:

CryptAcquireContext(&hProv,NULL,MS_DEF_PROV,PROV_RSA_FULL,0)

which results in NTE_BAD_KEY_STATE

and another

CryptAcquireContext(&hProv,NULL,MS_DEF_PROV,PROV_RSA_FULL,CRYPT_NEWKEYSET)

which results in NTE_EXISTS.

On several other PCs with varying Windows-versions, it works (it's a
routine,
that is supposed to create a new server certificate with a private key).

How - and when - can this happen?

Regards,

Michael

[John Banes [MS]]

The Microsoft software CSPs encrypt the private keys using DPAPI
(CryptProtectData), which encrypts this using a master key. The master key
is encrypted with the user password.

Things get a little tricky when the user's password is changed. The
NTE_BAD_KEY_STATE error code is returned when the master key can't be
decrypted. Typically, this is because the user's password has changed and
DPAPI wasn't able to deal with it. Have you changed you password recently?

The most common issue in this area occurs when a local (non-domain) user's
password is administratively reset. On WinXP, this causes all data protected
by DPAPI (including user private keys) to be lost; at least until the
password is set back. This is by design, and in fact is an important
security feature.

Regards,

John Banes
[Microsoft Security Developer]

This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"Michael Pflug" <bath.10....@spamgourmet.com> wrote in message
news:O4Q%23xrP8D...@TK2MSFTNGP10.phx.gbl...

[Michael Pflug]

Thank you, that sounds reasonable.
I can't tell whether the password has changed - it's a customer having this
problem.
I'll ask him.

So if I understand you right - the procedure should work, when another user
logs on (no workaround for the
problem, but a way to check if it is really a user-related problem)?
And: in case the original password of the failing user's account (it's the
local Admin!) can't be reset,
maybe because it's nont known anymore - is there a way to remove the old
keyset (there's nothing to be lost)
and regenerate a new?
Or in short: how do we get this PC back to work?

There is another symptom, I'd just like to know, if it is related:
There is also a routine to check whether there is a certificate in the
MY-store, that matches
certain criteria: usage: "Server Auth" and private key available.

This is actually the original problem - the server already had a working
certificate, but at once
the application started crashing, when trying to open the required
certificate.

It goes
CertOpenStore(Prov: NULL, Store: "MY")
(succeeds)
CertFindCertificateInStore(...)
which crashes. This only happens on the trouble-causing machine.

Also: what definitively was changed: the user added the "Internet
authentication service" and
"Certification service" before problems started (I hope I translated
correctly, I only know the
German localized terms).
Can these have any effect?

Regards,

Michael

"John Banes [MS]" <jba...@online.microsoft.com> schrieb im Newsbeitrag
news:OnEgW7S8...@TK2MSFTNGP11.phx.gbl...

[Michael Pflug]

I just got a reply from the customer, he says the Admins password was never
changed.
And the whole thing worked before, so something happened in between -
the suspects are, as mentioned, the two services "network auth svc" and
"cert service", but removing them didn't solve it.

So now all I need is a way to somehow reset the whole thing to zero... (?)

"John Banes [MS]" <jba...@online.microsoft.com> schrieb im Newsbeitrag
news:OnEgW7S8...@TK2MSFTNGP11.phx.gbl...