K2 Configuration Analysis – Could not create certificate: Keyset does not exist

I was doing K2 5.1 installation recently and bumped into the following error reported by K2 installer:

The following was recorded in installer trace:

>> Certificates.FindCertificate: Find cert start
>> Certificates.FindCertificate: Find certificate: D9F8C4EF74BD33B6C9FCA421E68222E77B1A3315 in LocalMachine – My
>> Certificates.FindCertificate: Found 1 certificates
>> Certificates.ExportCertToString: Exporting…
>> EnsureCertificate.Execute: Logged Error: Could not create certificate: System.Security.Cryptography.CryptographicException: Keyset does not exist

at System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr)
at System.Security.Cryptography.X509Certificates.X509Utils._ExportCertificatesToBlob(SafeCertStoreHandle safeCertStoreHandle, X509ContentType contentType, IntPtr password)
at System.Security.Cryptography.X509Certificates.X509Certificate.ExportHelper(X509ContentType contentType, Object password)
at SourceCode.Install.Security.Certificates.ExportCertToString(X509Certificate2 cert, String password)
at SourceCode.Install.Package.Actions.Security.EnsureCertificate.Execute(Target target)
>> EnsureCertificate.Execute: End EnsureCertificate, success: False
>> Target.Execute: !Completed: Server – EnsureCertificate, Success: False

It was really strange as everything was working fine and seemingly all required certificates were in place. I tried to check on “C:\ProgramData\Microsoft\Crypto\RSA” folder permissions but they were seemingly OK and updating/editing them didn’t resolve K2 installer error for me. Though as I later found out I was looking into the right direction. I next rebooted the server a few times and eventually lost RDP connectivity to it with the following error message displayed by MSTSC client:

At this point it was took over by Windows server admin who resolved MSTSC error after stumbling on the blog post at Ask the Performance Team Blog and correcting RSA folder permissions. As I understand final solution was… …drum roll… ensuring/fixing correct permissions on “C:\ProgramData\Microsoft\Crypto\RSA” folder. Specifically NT AUTHORITY\NETWORK SERVICE account didn’t have rights on “C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys” folder. Once permissions were adjusted it fixed both MSTSC connectivity and K2 installer error mentioned above.

My takeaways from this case and aforementioned blog post are the following:

– For RDP problem there was correlating server side even with ID 36870: A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

– In general if I’ll see this error next time I will run Procmon while reproducing this error/running installer with expectation that it will show an “Access Denied” error while trying to access some of the MachineKeys, e.g.:

“C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4”

Once we have access denied error spotted it should be possible to correct permissions with certainty that problem is indeed caused by them. As we had certificate GUID mentioned in K2 installer trace I assume there should be corresponding access denied error related with accessing this specific machine key which can be caught with help of Procmon utility.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *