During the installation of our program we run this method to encrpyt sections of the app.config:
// Get the application configuration file.
Configuration config =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// Define the Rsa provider name.
const string provider = "RsaProtectedConfigurationProvider";
// Get the section to protect.
ConfigurationSection connStrings = config.ConnectionStrings;
if (connStrings != null)
{
if (!connStrings.SectionInformation.IsProtected)
{
if (!connStrings.ElementInformation.IsLocked)
{
// Protect the section.
connStrings.SectionInformation.ProtectSection(provider);
connStrings.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
}
Works fine so far. But if I run this program, we encounter of several machines the following error "Failed to decrypt using provider 'RsaProtectedConfigurationProvider'. Error message from the provider: The RSA key container could not be opened".
Of course I searched and found this help, but this doesn't work. Any ideas?
I ran into similar issues while debugging within Visual Studio 2010 on Win 7 with UAC set to it's default protection.
In order for me to get around this issue, I had to run Visual Studio as the Administrator ("Run as Administrator").
I had the same issue with trying to run the aspnet_regiis.exe to encrypt the section of my web.config. If I didn't run the commandline/console "as Administrator" I would get a commandline error that was even more cryptic: "Object already exists."
Yes.
Reason is those machines working have RsaProtectedConfigurationProvider setup in their machine.config. Those not working, don't have it - just manually add it for those machines.
I imagine that's one of the steps aspnet_regiis.exe does. I can't imagine you want to run that on all client machines.
UPDATE
OK, I have made the main part of the error in bold in your question - you are right it is a different issue. It is a security issue. If you look at the location C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys or C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys depending the operating system, you see a number of files. Your process does have access to the folder so just give files access to the whole folder for the identity of the application or a particular file (timestamp will tell you if you have created it).
I got this on an app.config that was running on a Windows Server set up as a SQL Server. It did not have IIS installed. The machine.config file listed RSAProtectedConfigurationProvider as the default, but when we looked in the two folders mentioned by Aliostad above the folders were empty.There were no keys installed. We used the aspnet_regiis tool to create a custom key. then we used it to grant access to the identity the batch job runs under. All of this was running cmd.exe and aspnet_regiis As Administrator.
Related
I'm getting the following error message from Visual Studio 2017 on first run of the ASP.NET Core MVC Boilerplate template (DotNet Core) regarding the SSL certificate:
"Internal.Cryptography.CryptoThrowHelper.WindowsCryptographicException
occurred HResult=0x80070002 Message=The system cannot find the
file specified Source=
StackTrace: at
Internal.Cryptography.Pal.CertificatePal.FromBlobOrFile(Byte[]
rawData, String fileName, String password, X509KeyStorageFlags
keyStorageFlags) at
System.Security.Cryptography.X509Certificates.X509Certificate..ctor(String
fileName, String password, X509KeyStorageFlags keyStorageFlags) at
Microsoft.AspNetCore.Hosting.KestrelServerOptionsHttpsExtensions.UseHttps(KestrelServerOptions
options, String fileName, String password) ... "
All other projects using SSL work fine and I've double checked that my localhost certificate is in the Trusted Root Certification Authorities for my local machine and has not expired.
The project is running IISExpress - perhaps it's not looking the correct place? I'm not sure. Any ideas where I'm going wrong?
Recently had this same issue with ASP.NET Core MVC Boilerplate.
Close Visual Studio, right click on it, "Run as Administrator". Worked for me.
One of two problems is going on.
1) The file "exists", but is a symlink. That tends to confuse the underlying system. (The response is to do File.ReadAllBytes and use the byte[] constructor).
2) The file doesn't exist.
To help diagnose #2 you can read Environment.CurrentDirectory to know where "here" is, and use Directory.EnumerateFiles() to see what is present in the directory and why your file doesn't exist.
Of course, if you didn't think you were loading by file, but thought you were loading from a certificate store: Check your configuration and try again... since you're loading from file :).
If you're running in docker, another workaround is doing a copy at startup.
# The copy is done, because wildcard_certificate.pfx is put into the container using docker secrets, which makes it a symlink.
# Reading a certificate as a symlink is not supported at this moment: https://stackoverflow.com/q/43955181/1608705
# After doing a copy, the copied version is not a symlink anymore.
ENTRYPOINT (IF EXIST "c:\certificates\wildcard_certificate.pfx" (copy c:\certificates\wildcard_certificate.pfx c:\app\wildcard_certificate.pfx)) && dotnet webapplication.dll
My application runs in the "c:\app" folder and I put my "to be copied" certificates in "c:\certificates". At startup the certificate is copied to "c:\app", which my environment variables point to.
version: "3.7"
services:
webapplication:
image: ({CONTAINER_REGISTRY})/webapplication:({LABEL})
environment:
- ASPNETCORE_URLS=https://+;http://+
- ASPNETCORE_HTTPS_PORT=443
- ASPNETCORE_Kestrel__Certificates__Default__Path=wildcard_certificate.pfx
secrets:
- source: config_secrets
target: C:/app/appsettings.json
- source: wildcard_certificate_pfx
target: c:\certificates\wildcard_certificate.pfx
Context
I'm setting up a new dotnet 6 mvcapp website and trying to install Certbot generated certificate locally. The settings for kestrel to load certificate from file was simple enough but I keep getting above errors.
Reason for that like someone has mentioned, the fullchain.pem is actually a symlink or in other word: a shortcut.
Solution for that is to right click on the '.pem file' shortcut and select Open file location and then get the actual .pem files.
Updating your settings to point to the actual files and you should be ok.
Wrong path points to live folder
"Certificates": {
"Default": {
"Path": "C:\\Certbot\\live\\{my domain}\\fullchain.pem",
"KeyPath": "C:\\Certbot\\live\\{my domain}\\privkey.pem"
}
}
Correct path points to archive folder
"Certificates": {
"Default": {
"Path": "C:\\Certbot\\archive\\{my domain}\\fullchain.pem",
"KeyPath": "C:\\Certbot\\archive\\{my domain}\\privkey.pem"
}
}
I've just spent all morning fixing this error....
I'm using the Azure.Security.KeyVault.Certificates nuget package to download a certificate from a KeyVault and use it for IdentityServer.
I recently updated nuget packages for our project so refactored a bit of code, deleting the key bit of the jigsaw.
var signingCertificate = certificateClient.DownloadCertificate(new DownloadCertificateOptions(signingCertificateName)
{
KeyStorageFlags = System.Security.Cryptography.X509Certificates.X509KeyStorageFlags.MachineKeySet,
});
X509KeyStorageFlags.MachineKeySet is the secret sauce to getting it running on Azure. I tried several other options before landing back on this one. The annoying thing is, had this in originally before I started refactoring!
Using VS 15, C# with .Net 4.5.2
The computer is on an AD network, with the ad name "AD".
This problem happens with AD normal-user rights, AD admin rights, and local admin rights. It doesn't matter what rights the program gets, the same problem occurs.
Our test file is "C:/windows/system32/conhost.exe".
The file above exists, it is very much existing. I can see it with explorer.
This is the file in explorer:
This is the file properties:
You can see that it is there, right?
The following cmd command checks if the file exists:
IF EXIST "C:\windows\system32\conhost.exe" (echo does exist) ELSE (echo doesnt exist)
It returns "does exist" as promised.
The following C# code checks if the file exists:
FileInfo file = new FileInfo("C:/windows/system32/conhost.exe");
MessageBox.Show(file.Exists + "");
This returns "False".
This code also returns "False":
MessageBox.Show(File.Exists("C:/windows/system32/conhost.exe") + "");
This code also doesn't find it:
foreach (string file in Directory.GetFiles("C:/windows/system32/"))
{
//conhost is NEVER mentioned, like it doesn't exist
}
This code also doesn't find it:
foreach (string file in Directory.EnumerateFiles("C:/windows/system32/"))
{
//conhost is NEVER mentioned, like it doesn't exist
}
False, False, False:
MessageBox.Show(File.Exists("C:/windows/system32/conhost.exe") + "");
MessageBox.Show(File.Exists("C:\\windows\\system32\\conhost.exe") + "");
MessageBox.Show(File.Exists(#"C:\windows\system32\conhost.exe") + "");
What am I doing wrong?
Extra note: I copied conhost to C:\conhost.exe, and my program can find that without problem. My program also finds other files in system32, just not conhost and a few others. For example, it finds "connect.dll" which is in system32, so it's not the directory's read permission.
More extra notes: conhost.exe and connect.dll has the same security attributes (Security tab in the file properties).
If you are using x64 system, you will have different content of the c:\Windows\System32 directory for x86 and x64 applications. Please be sure that you are using same architecture running batch file and your C# app.
In the MSDN documentation for System.IO.File.Exists(path), it states:
If the caller does
not have sufficient permissions to read the specified file, no
exception is thrown and the method returns false regardless of the
existence of path.
For this reason, we can safely assume that your application does not have read access to that specific file. Check the security settings and grant read access if not already done so.
Build your application (in release mode) and run as administrator.
This is the problem that come over 64-bit operating system... here is a work around,
go to the project's properties > click on build tab > untick Prefer 32-bit
after that, it should work correctly over 64-bit os.
I faced very strange behaviour - after I overwrite .NET exectables with new versions from network drive it cannot start.
When try to start from Windows Explorer it shows me following error:
[Window Title]
C:\Programs\zzz\clients.net\zzzNet.exe
[Content]
C:\Programs\zzz\clients.net\zzzNet.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
I tried to execute following commands:
SxsTrace Trace -logfile:SxsTrace.etl
SxStrace Parse -logfile:SxSTrace.etl -outfile:SxSTrace.txt
And got following result:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = AMD64
CultureFallBacks = en-US;en;ru-RU;ru
ManifestPath = C:\Programs\zzz\clients.net\zzzNet.exe
AssemblyDirectory = C:\Programs\zzz\clients.net\
Application Config File = C:\Programs\zzz\clients.net\zzzNet.exe.Config
-----------------
INFO: Parsing Application Config File C:\Programs\zzz\clients.net\zzzNet.exe.Config.
INFO: Parsing Manifest File C:\Programs\zzz\clients.net\zzzNet.exe.
INFO: Manifest Definition Identity is (null).
ERROR: Line 0: XML Syntax error.
ERROR: Activation Context generation failed.
End Activation Context Generation.
It is quite simple .NET application (1 exe + 8 dll files). It was built for .NET 3.5 Client Profile.
I not defined any special "manifest" there. Just clicked "New Windows Forms Project" in Visual Studio and developed it.
Also app.config does not contain anything special - only primitive standard settings - appSettings and userSettings sections.
On PC where I developed it all is perfectly works. Problems only began when I copy these binaries to this particular VM and try to start.
Also please note - these executables were not installed in GAC or such, I just copied them into a folder on VM and started. And when it was 1st time all was working fine.
So, the problem pattern is following:
Copy .NET execuatbles to new VM (it is Win 7 x64), run it, all is working fine. Close it.
Build new version of .NET execuatbles on host PC, copy new .NET execuatbles to VM (with files overwriting).
Try to start - got mentioned problem.
After some shaman-style actions (like OS reboot, etc) it begin to work but why that happened at all?!
Why replacing .NET executables with new versions is causing SUCH HUGE PROBLEMS?!
Also the BIG QUESTION - is there any special procedure to replace .NET executables to keep them working? Because it is a new app development, I do not want lost so much time on every new executables installation. :-\
Could you please help? Because it looks completely weird!
Thank you in adance.
PS. I checked all VS projects - all they have PlatformTarget=AnyCPU. Also in run-time I can see ProcessType=MSIL (I show this info in AboutBox for application). So, there is no mix of x86/x64 binaries.
It seems that was related to mapped network drive behavior.
When I copied new files from network drive folder it copied wrong files - a strange random mess of new files and older ones (which were there before I updated them on VM host).
The scenario to make it working:
on VM: delete all files in a folder on network drive
on VM host: copy new files into a folder which is mapped as network drive on VM
on VM: copy files into target folder
on VM: run application - it works now
Weird thing. I remember I have seen something similar with Windows Explorer on Windows 2008 behaviour when copying updated win32 binaries.
I want to open one document file on our website. For that I write following code.
try
{
Process proc = new Process();
proc.StartInfo = new ProcessStartInfo(Server.MapPath("~/Quatation/PREMIUMQUOTATION1.doc"));
proc.Start();
}
catch (WebException we)
{
}
It runs locally very fine but web on web server it gives me an error like
System.ComponentModel.Win32Exception: Access is denied?
Please suggest, what should I do?
I had this problem when my .NET Target Framework was set to 4.5.2. I fixed it by changing the target framework version to 4.5. To do this using Visual Studio 2015, open Solution Explorer, right click on your solution and click Properties. The "Target Framework" should be set to ".NET Framework 4.5". Additionally, if you previously built with a target framework other than 4.5, you may have a <compiler> section in your web.config, and this may throw an error when you build. Just remove this section to fix the issue. Removing it should not cause any problems.
I wrote a short article about this here that has a couple other things to try that didn't work for me but might work for you.
Also check out This Stack Overflow answer which also helped numerous people with this error!
may be your SQL server is off
check it in services and start it
It sounds like you haven't changed the service logon user. You can do it from service control manager by right clicking the service and go to the Logon tab.
Then add user as Service Logon User
Or you can do it from the command line:
sc config ServiceName obj= Domain\user password= pass
Note the space between obj= and Domain\user it is not a typo. It is required. The same for password=.
My problem solve with this
In IIS Manage->Pool Application->Advance Setting->Identity
change to Custom Account and set Administrator User
Goto windows explorer and right click on the folder "~/Quatation/". Select properties and pick the Security tab to give permissions. In the case where your application pool under which the web application runs is using a domain account, you will need to give that specific domain account permission.
I faced the same issue while running my website from local IIS, after spending some time reading the project properties, found that, certain changes to the project properties were not saved...
Once it was saved, the error went away...
I got this error while I was working in visual studio 2017, using dotNet framework 4.5, in MVC project...
If you are getting this exception maybe you don't have the administration rights to your system so check with your admin and ask for the rights. If you do have administrator rights please open your IDE(e.g Visual Studio as an Administrator).You might also get this exception if you are trying to access the processes of 32 bit configuration system but your system has 64 bit configuration.
I am using .Net 4.5.2 and IIS 8.5.9
In IIS Manage->Pool Application->Advance Setting->Identity change
ApplicationPoolIdentity to Custom Account and set Administrator User
I have setup my TeamCity to build using MsBuild a project that NuGet packages.
During the build, the following command to install packages is issued, but fails:
..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server
with exit code 1.
Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.
This is what I have done so far:
Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
To provide the additinal paths ways to supply a path:
Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)
What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?
Do you have any ideas of what to try?
The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.
I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.