Cryptographic failure while signing assembly

If you are having a problem using Fortress, post a message here.

Moderator: SourceGear


Posts: 3
Joined: Tue Mar 10, 2009 10:27 am
PostPosted: Tue Mar 10, 2009 10:43 am
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.

Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear
PostPosted: Tue Mar 10, 2009 2:32 pm
Any help here?

viewtopic.php?f=5&t=3027&p
Linda Bauer
SourceGear
Technical Support Manager

Posts: 3
Joined: Tue Mar 10, 2009 10:27 am
PostPosted: Fri Mar 13, 2009 7:01 pm
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...

Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
PostPosted: Sat Mar 14, 2009 3:00 pm
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.
Beth Kieler
SourceGear Technical Support

Posts: 3
Joined: Tue Mar 10, 2009 10:27 am
PostPosted: Tue Mar 17, 2009 5:16 pm
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?

Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
PostPosted: Thu Mar 19, 2009 7:34 am
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?
Subscribe to the Fortress/Vault blog

Posts: 1
Joined: Tue Mar 31, 2009 8:29 pm
PostPosted: Tue Mar 31, 2009 8:38 pm
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/2005/12/01/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.

Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear
PostPosted: Wed Apr 01, 2009 10:23 am
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.
Linda Bauer
SourceGear
Technical Support Manager

Posts: 1
Joined: Fri Feb 12, 2010 2:54 pm
PostPosted: Fri Feb 12, 2010 2:59 pm
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.

Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear
PostPosted: Tue Feb 16, 2010 2:30 pm
Thanks for the info.
Linda Bauer
SourceGear
Technical Support Manager

Posts: 6
Joined: Sat Nov 20, 2010 5:01 pm
PostPosted: Sat Nov 20, 2010 5:34 pm
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!

Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
PostPosted: Mon Nov 22, 2010 4:55 pm
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
Beth Kieler
SourceGear Technical Support

Posts: 6
Joined: Sat Nov 20, 2010 5:01 pm
PostPosted: Tue Nov 23, 2010 7:44 am
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?

Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
PostPosted: Tue Nov 23, 2010 9:35 am
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?
Beth Kieler
SourceGear Technical Support

Posts: 6
Joined: Sat Nov 20, 2010 5:01 pm
PostPosted: Wed Dec 01, 2010 3:21 pm
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.
Next

Return to Support (Fortress)

Who is online

Users browsing this forum: No registered users and 10 guests

cron