jmanzano@ Thanks for the issue.

Could you please provide us any sample test file or URL and screen shot of the issue to triage it from test team end.

Thanks,

I've set up a test environment here: https://goo.gl/0JRAkk

It uses <keygen> and issues a certificate from our development CA matching the key pair. It can be called may times and a new certificate will be issued every time.

Deleted: screenshot.png 672 KB

	screenshot.png 672 KB View Download

Thank you for providing more feedback. Assigning to requester "kavvaru@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

I can confirm that in the test site, a valid key is being generated (using DevTools and net-internals, I could see that the posted form data includes the field 'csr', which contains a valid SPKAC for the challenge ID), and the public key in the SPKAC and the signature match. So we're at least generating a key.

On importing, Windows is opting for the Other People store. If forcing the "MY" store explicitly, MMC still doesn't pick up that a key was generated. This doesn't make much sense, because the keys are indeed being generated and persisted (to %APPDATA%\Microsoft\Crypto\RSA since we're using the CAPI routines rather than CNG).

Our <keygen> handling code never did any special handling for certificates explicitly, but in checking for the private key's existance, we were calling CryptFindCertificateKeyProvInfo on the OSCertHandle prior to importing. That has the subtle effect (in the remarks) of setting the CERT_KEY_PROV_INFO_PROP_ID on the certificate.

I'm tentatively thinking this as a WontFix, because I can confirm that the key exists and everything is working correctly from the speced/expected behaviour. The OS is unable to find the private key because *it's not even looking for it*. The importer arguably should be searching for the key on import, which would be a bug in the Windows side. Certainly, there are no plans to add special handling back for certificate mimetypes back, and this is a general problem that would exist with any certificate import (e.g. pre-provisioned from a smart card, for example).

I'm marking it assigned, to explore if using the CNG routines have any different effect with respect to the import pipeline, but otherwise, Works As Intended.

Judging by https://support.microsoft.com/en-us/kb/889651, apparently, this is "WAI"

From an elevated command-line prompt, running
certutil -repairstore -user my "SerialNumber"

Successfully reassociates the private key.