When trying to create a PrivateKeyFile object I get the following error:
Access to the path is denied.
Here is the code:
PrivateKeyFile pk = new PrivateKeyFile(keyfile);
I have tried to tweak the Windows security settings (to the point where I set Full Access to Everyone) and that still hasn't solved my issue.
There is no pass phrase for the key.
Anyone run into this? If so do you have a solution?
Thanks.
I appear to have found my problem. The original key was generated on an AIX server. I did check it with PuttyGen, which acknowledged it as an OpenSSL private key.
However, I decided to run the Conversion to OpenSSL anyway. Once I did that and tried again, it worked and allowed me to connect to the server.
So that seems to be the problem.
Related
I'm trying to set a Certificate for identityserver and it keeps failing with a "no access to private key error".
Taking it out of identityserver, the following code throws an access denied error
static X509Certificate2 GetCertificateFromDisk()
{
using (var stream = File.Open(#"patht-to-pfx", FileMode.Open))
{
var cert = new X509Certificate2(ReadStream(stream), "password", X509KeyStorageFlags.MachineKeySet);
return cert;
}
}
When running the code as administrator it works fine, not when running it under my own account. Eventually I want to run it as localsystem.
I even added 'Everyone' under the certificates private key permissions in my local computer certificate store,
screenprint here
... still I get the exception.
What is wrong here? Going Crazy about it
Update
Great tips from CryptoGuy in the answer below. Important note: Opening the file is not correct only Identityserver3 still failed when getting the certificate from the store. What made it work was to regenerate the certificate using Keith Sparkjoy's tool SerfCert. My previous certificate was generated using powershell. So keep in mind that powershell certificates have issues with accessibility of private key. Thanks to Keith for the tool!
There are few things to consider.
1) you are performing write access to Local Machine store. X509KeyStorageFlags.MachineKeySet attempts to save private key to Local Machine store. Therefore, you need administrator permissions to write there. You should remove this flag to perform read-only access
2)
Documentation says that adding permissions in MMC (manage private key-option on a certificate) should allow this, but it doesn't seem to work
it works on an already saved private keys.
What you really should do is to import certificate and private key to Local Machine store and then configure your application to reference installed certificate.
3) if your application runs under unpriveleged account and the key don't need to be shared, then you should use Current User store.
I'm trying to use the CryptImportKey function to import a PFX into a Gemalto .NET IDPrime smart cart, but I'm getting a "Invalid Type Specified" (2148073482) error. I suspect that the RSACryptoServiceProvider.ExportCspBlob(true) call is returning the keys in the wrong format. I'm using sample code from http://www.idrix.fr/Root/Samples/PfxImporter.cs. NOTE: I've already set the AllowPrivateExchangeKeyImport & AllowPrivateSignatureKeyImport to 0x1 for the Microsoft Base Smart Card Crypto Provider, but still no change. I'm running Windows Server 2012, but don't think that is the issue.
Can someone please tell me what is wrong with this code sample?
Your issue is certainly caused by the fact that your application is 32-bit running on a 64-bit Windows and you didn't change the Microsoft Base CSP 32-bit registry key located under Wow6432Node.
To solve your issue, change AllowPrivateExchangeKeyImport & AllowPrivateSignatureKeyImport also under "HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smart Card Crypto Provider".
I have update the comment in PfxImporter.cs header to include this remark.
I am trying to add a registry key in my C# code under
HKEY_CLASSES_ROOT\*\shell\blabla
I want the user to be able to send any file to my application, kind of like Open with UltraEdit or so.
I don't have administrator rights and the users won't have administrator privileges, too.
If I am doing that in my C# code as posted below, I get a
System.UnauthorizedAccessException
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla", null, "FastSearch");
string path = Application.ExecutablePath;
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla" + "\\Command", null, path + " \"%1\"");
If I run Regedit and attempt to do it manually myself, I get a similar error:
Error! Key could not be created. Error when writing to the registry.
BUT, if I double click a *.reg file that attempts to write the SAME KEY, everything works!
So why is that?
And do I have a chance to get this done through code?
Or should I just change my code to run that *.reg file?
UPDATE:
Actually the *.reg file did not write the SAME KEY as stated above, but
HKEY_CURRENT_USER\Software\Classes\*\shell\blabla
I didn't notice that. It seems as anything added under HKEY_CURRENT_USER\Software\Classes*\shell\blabla is also added to HKEY_CLASSES_ROOT\*\shell\blabla. Sorry for the confusion.
Although the problem is solved already and the reason for successful import of *.reg file was found out also in the meantime in comparison to C# code, here is a complete answer for this question.
HKEY_CLASSES_ROOT Key (short HKCR) as described by Microsoft shows file name extension associations and COM class registration information which are effective for the current user.
The real locations in registry for those keys are:
HKEY_LOCAL_MACHINE\Software\Classes (short HKLM\Software\Classes) containing the defaults for all users using a machine and
HKEY_CURRENT_USER\Software\Classes (short HKCU\Software\Classes) containing the user specific settings which override the default settings from HKLM\Software\Classes.
A registry write to HKEY_CLASSES_ROOT is always redirected to HKLM\Software\Classes. A write access to any key in HKLM requires administrative privileges which is the reason for the error message.
Microsoft recommends to write directly to either HKLM\Software\Classes or to HKCU\Software\Classes depending on changing the defaults or the effective file associations for the current user.
Write operations to keys under HKCU do not require administrative privileges.
HKCR should be used only for reading currently effective settings for file name extension associations and COM class registration information and not for adding or changing them.
I am developing a c# .net 3.5 application on Windows 8.
I need to encrypt data using DPAPI. it works ok on all of my machine except from one machine where I get the following exception: System.Security.Cryptography.CryptographicException Message: Access is denied.
byte[] bytes;
bytes = ProtectedData.Protect(Encoding.UTF8.GetBytes(argsStr.ToString()), null, DataProtectionScope.CurrentUser);
when I change the DataProtectionScope.CurrentUser to DataProtectionScope.LocalMachine it works ok.
It seems that someone has denied the access of the current user to preform DAPI encryption
What can i do to fix this issue?
The application that fails is a console application running under the current logged in user.
When running the application using elevated privileges it still failed with access denied.
I tried to reset the login password and it solved the issue.
How can something like that happen?
This happened because the MasterKey of DPAPI was not in sync.
Typical causes are :
password changed administratively (without providing the old one and not in a domain - net user administrator password)
third party authentication package
You can manually sync the MasterKey in code using CryptProtectData(CRYPTPROTECT_CRED_SYNC)
regards,
vincent
I had the very same problem in a case when the user did not have a password defined on Windows 7. The solution was to set a password for the user.
I'm trying to publish the new deployment of my application to a shared location.
and I get this error "An error occurred while signing: Key not valid for use in specified state."
Note This is the first time doing so since moving to a new domain.
The shared location is in the old domain and at first I thought it was because it couldn't access the information necessary in the old share location because I didn't apply my credentials to access the old share, which could be a reason the key information could be mismatched.
after logging on with my credentials it didn't help.
Just adding to an old question because I just had this problem after a domain change and already had a valid signing certificate working on the project. Had to re-import it and it worked after that.