Cryptographic failure while signing assembly

[Radius1]

I have a large VS2008 solution with 40+ projects. Most of the projects produce signed C# assemblies.

Before installing Fortress, the solution built with no problems. After installing Fortress, none of the projects that produce signed assemblies will build. They all produce this sort of error:

error CS1548: Cryptographic failure while signing assembly 'C:\Projects\Accelerator\AcceleratorSolution2008\AVSCommon\obj\Release\AVSCommon.dll' -- 'Access is denied. '

I've researched the issue and found numerous references on the web that indicate that the logged on user must have full access rights to the folder 'C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys'.

I am logged on to the computer with a Windows account that is a member of the local Administrators group. I've checked and my user account has full access rights in this folder. My account also has full access rights to the \Projects folder and all sub-folders.

If I change project settings so the assembly is not signed, it builds with no problems (but is not a viable solution).

The OS is Windows Server 2003.

I'm really stumped. Any suggestions will be greatly appreciated.

[lbauer]

Any help here?

http://support.sourcegear.com/viewtopic ... 5&t=3027&p

[Radius1]

The topic you referred me to simply rehashes the issue of having full access rights in the folder 'C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys', which I already commented on in my initial post. So, no, no help there...

[Beth]

Have you checked the access rights to the .dll? You might try just using the Everyone account for testing this. Give that account full control to the .dll and see what happens. If nothing changes, then I would try that same account on the RSA Machine Keys as well. If with both have everyone set at Full Control, you get the same error, let us know and we'll go from there. You can also place permissions back the way they were.

If my idea does work, then the issue is very well narrowed down, and then it's just a matter of finding the right permission.

[Radius1]

I don't see how it can be an access rights issue. I am logged on with a domain account that is a member of the local Administrators group. I have full access to every folder, file, registry key, etc.

The DLL doesn't exist because I did a rebuild all, which cleans the build folder before building.

I'm really confused because every project in this solution built fine before installing Fortress. Now, none of the signed projects will build. That would seem to indicate that either Fortress changed some system settings during install (like revoking rights to specific files, folders or registry keys) or something about the Fortress Visual Studio plug-in is causing this problem.

Nobody else has experienced this issue?

[jeremy_sg]

To answer your last question, no, this error does not come up often.

Some observations.

1. http://blog.devstone.com/aaron/archive/ ... /1365.aspx would lead me to believe that fixing the permissions in your MachineKeys directory will fix it. You should check the permissions of all the files in that directory as well, in case they are not inheriting the folder's settings.

2. I don't think that the client install touches that directory's permissions. Did you install the server?

[MrEks]

I experienced the same problem: I had a Visual Studio 2008 project that was signed and it built fine. Then I installed the Fortress server (not the client) for an eval, and the project would no longer build, giving me "Cryptographic failure while signing assembly ..... 'Access is denied. '". It was quite maddening and I never suspected that the Fortress install was related. I came across http://blog.devstone.com/aaron/archive/ ... /1365.aspx and dismissed it since it talked about a machine rebuild, which did not fit my scenario. Google finally brought me to this thread, and I saw that page referenced again. I went back and followed the recommendation, and presto, the project now builds cleanly. So, after an hour of head scratching I'm working again. Sure seems like the Fortress server install stomped something.

This is on Win XP, and I run as an administrator level account.

[lbauer]

The Vault/Fortress server installation does add Read/Write/Modify permissions to %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys for the account you choose in the IIS Process Model portion of the installation. It shouldn't be changing anything else, but it's possible something did change in your case.

[genov]

I had exactly the same issue after installing Vault Server Trial on Win7Pro, running VS2008 as an Admin.
The fix was to take ownership of everything under C:\Users\All Users\Microsoft\Crypto\RSA\MachineKeys and make sure local admin group has full access on that same folder with all its children.

[lbauer]

Thanks for the info.

[BillB4]

I just installed Vault Server 5.1 and this Installer bug is still an issue.

Everything is installed on one machine running Windows 7.

The installer changed the permissions on "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys". It removed access for Everyone and Administrators then added full control for IUSR and VaultAppPool. It should have left Everyone and Administrators alone.

Having to Google for, and then apply the fix manually, is not a real soultion to this problem!

[Beth]

I'll log a bug on this and take a closer look. This doesn't seem to happen for most users. I'll post back once I check this out.

F: 15752

[BillB4]

Update

In order to get signed compilation working again, I had to go through several steps:

1) Uninstalled Vault Client. Signed compilation still broken.
2) Uninstalled Vault Server. Signed compilation still broken.
3) Performed a System Restore back to before Vault was installed. Signed compilation now works again.

Before I did these steps, I took a closer look at the permissions on the MachineKeys folder. The installer added IUSR and VaultAppPool with Full Control. Everyone and Administrators had Special Access; I did not dig into what specific access they had. The padlock overlay icon was missing from this folder.

After the restore, the RSA MachineKeys folder has Everyone and Administrators with Special Access and the padlock overlay icon appears. iCALCS shows:

Everyone:(R,W)
BUILTIN\Administrators:(F)

Administrors have full control and Everyone has read/write with no delete. This is consistent with the DSS MachineKeys folder.

Is there really any reason to change the folder security when installing on Windows 7? Perhaps this was needed with a prior version of Windows? Why would IUSR and VaultAppPool need full access?

[Beth]

Vault uses the RSA keys for hand-shaking and key exchange with the server, and so the account the VaultService App Pool runs under needs permissions to create and read the keys for Vault.

The installer places the same permissions on that folder regardless of OS.

If I'm reading this correctly, in the first install, you lost some permissions on the Machine Keys folder, and in the second install, you didn't lose the permissions that were set before. And in both cases Vault added the permissions it needed. Does this sound correct?

[BillB4]

There was only one install. My last post detailed what I had to do *AFTER* uninstalling Vault in order to get signed assemblies to compile again.

There is absolutely no reason to alter the permissions on Machine Keys--especially since it is breaking signed assembly compilation. "Everyone" has R/W permission by default in Windows 7. Why change that? Machine Keys is a Microsoft folder. That should not be touched by other applications.

Bottom line: The Vault installer is altering permissions on this folder. Whatever it is doing causes the compilation of signed assemblies to fail. Uninstalling it and performing a System Restore is the only way to get signed assemblies to compile again.