Category Archives: Crypto

Sorting out Digital Certificates – Dec 2012 Boston Azure Meeting

At the December 13, 2012 meeting for Boston Azure Cloud User Group, I gave a short talk on how Digital Certificates work (cryptographically speaking).

The backstory is that Windows Azure uses certificates in a few different ways, and understanding the different types of certificate uses is key to understanding why these different ways of using and deploying certificates are the way they are.

The slide deck is here:

Sorting Out Digital Certificates – 13-Dec-2012 – Bill Wilder – Boston Azure




Resolving “certificate for the given thumbprint could not be loaded” error with Azure Tools for Visual Studio

Recently I encountered a strange error when attempting some storage-related activities using Windows Azure Tools within Visual Studio 2012. When either adding a new storage account or changing Connection String settings I was met with:

The certificate for the given thumbprint could not be loaded from the Current User/Personal certificate store. Please install the certificate.

While I was able to resolve the error, I cannot reproduce it (and gave up trying), but if you face the same problem, hopefully this will help you.


If Visual Studio was looking for a certificate, where was it looking? It turns out that the Windows Azure Tools for Visual Studio store some certificate related references in a file called Windows Azure Connections.xml in your personal settings area on Windows. This file is created on your behalf once you’ve created any Publish Profiles by Publishing Cloud Services to Windows Azure from Visual Studio.

The file lives here:

%UserProfile%\Documents\Visual Studio 2012\Settings\Windows Azure Connections.xml

On my Windows 8 development machine, this is:

C:\Users\billdev\My Documents\Visual Studio 2012\Settings\Windows Azure Connections.xml

The file contains the credentials you’d previously supplied during publishing and will look something like the following:

<?xml version=”1.0″?>
<NamedCredentials xmlns:xsi=”” xmlns:xsd=””>
<Name>Page of Photos</Name>
<LastUsedName>Page of Photos</LastUsedName>

Note that the NamedCredential XML element item may be repeated.


The problem turns out to be that one of the certificates referenced (identified by thumbprint via CertificateThumbprint XML element) either it is not installed properly locally, or not installed in the associated Windows Azure Subscription (identified by SubscriptionId XML element).


For each certificate referenced by a CertificateThumbprint element (there could be more than one, unlike the simple example shown above):

  1. Make sure the certificate is installed in your Local Certificate store and contains a Private Key – which usually can be found in the Personal (or “My”) store name under the Current User certificates by using the Certificates Snap-in with Microsoft Management Console. (You can also use certmgr.exe or write your own code to dump certificate info). (If the certificate exists in your local certificate store then it is probably fine. It is not likely it is missing a Private Key. But it is possible.)
  2. Make sure the certificate has been uploaded to the Windows Azure Portal for the SubscriptionId  referenced within Windows Azure Connections.xml.

That’s it. Should work. Worst case you can delete each element of your Windows Azure Connections.xml profile and start over.

Specific Scenarios

These are the two specific scenarios where I saw the problem in case you are interested.

Scenario #1

This scenario failed whether or not a project was open.

  1. Open the Server Explorer window in Visual Studio
  2. Right-click on Windows Azure Storage, choose “Add New Storage Account…“, and the error dialog appears:
    “The certificate for the given thumbprint could not be loaded from the Current User/Personal certificate store. Please install the certificate.”
  3. This message is extra confusing since I don’t think there ought to be any certificates involved here. And no project/solution is open.

Scenario #2.

This scenario requires an open Azure project.

  1. Open the UI tool for editing Azure configuration by opening your Cloud Project in Solution Explorer, drilling into Roles, and double-clicking on a Web Role or Worker Role project. The Role configuration editor window opens in Visual Studio.
  2. Choose Settings, then Add Setting (which creates Setting1 of Type=String), change Setting1‘s Type to Connection String, and the click the “…” button at far right (to pop up the connection string edit window), and an error dialog appears:
    “The certificate for the given thumbprint could not be loaded from the Current User/Personal certificate store. Please install the certificate.”

Here are the screen shots for the two error dialogs (slightly different).


Iterate through all certificates in the Certificate Store on Windows Azure

Pretty simple generic C# code to iterate through all certificates in the Windows Certificate Store and dump some metadata about each to standard output. Note that it really gets ALL certificates and doesn’t hard-code any stores or locations.

And just for fun, here is a dump of the certificates running on a Windows Azure Web Role (I did not install any add’l certificates on this instance):

Three ways to tell if a .NET Assembly (DLL) has Strong Name

Three ways to tell if a .NET Assembly is Strongly Named (or has Strong Name)

Here are several convenient ways to tell whether a .NET assembly is strongly named(English language note: I assume the form “strongly named” is preferred over “strong named” since that’s the form used in the output of the sn.exe tool shown immediately below.)

Towards the end, this post discusses use of Strong Names with Silverlight.

Then in the final section of this post the often confusing – though very important – differences between Strongly Named assemblies and Digitally Signed assemblies are clarified.

But first, here are three approaches for telling whether a .NET Assembly is Strongly Named...

Approach #1: Testing for Strong Name on Command Line or in a Script

You tell whether an Assembly/DLL has been successfully strong-named using the Strong Name Tool (sn.exe) (which can be found somewhere like here: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe) by running the following at the command line:

sn -vf System.Data.dll

Here are the results when running against a strongly named assembly, then one that is not strongly named.

C:\> sn -v C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembly 'C:\...\System.Data.dll' is valid
C:\> sn -v C:\WINDOWS\ismif32.dll
Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
C:\WINDOWS\ismif32.dll does not represent a strongly named assembly

Since the return value from sn.exe is 0 (zero) when the strong name is in place, and 1 (one) if not correctly strong named, you can test for this in a script by examining ERRORLEVEL, as in the following (put it into a text file called “sn-test.bat” for example and run as “sn-test foo.dll”):

@ echo off
if "%1"=="" goto END 
sn -q -vf %1 > NUL 
echo Has strong name: %1
goto END
echo Not strong named: %1
goto END

Note that this will tell you whether it has SOME strong name, but does not tell you which one. So this technique is not appropriate for all uses, but might help in, say, an automated script that checks your about-to-be-released assemblies to make sure you remembered to add the strong names to them. (See note below – “Strong Names not for Security”.)

If you need finer-grain control and wish to write low-level code to ascertain the strong-naming status of an assembly, you can do that too.

Approach #2: Viewing Strong Name Details with IL DASM

Visual Studio ships with a handy utility – the Microsoft Intermediate Language Disassembler (ILDASM.EXE (tutorial)) – which can be used for disassembling .NET binaries to peruse the contents, perhaps for viewing the method signatures or viewing the .NET Assembly Manifest. It is helpful to load an assembly using IL DASM and examine the manifest to see whether there is a strong name key available. Your first step is to load the desired Assembly using the ildasm.exe utility. On my Windows 7 machine, IL DASM is found at

C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ildasm.exe

and you can load up the System.Drawing.dll .NET Assembly as in the following example:

C:\> ildasm C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll

Once loaded, you will see a screen like the one below.

Note the MANIFEST section highlighted. Double-click on MANIFEST which load the following screen of manifest-specific data:

Find the section for the Assembly you’ve loaded – in this case, System.Drawing and following the section (which is marked with the “.assembly System.Drawing” directive highlighted above, and the content begins with the opening brace (“{“) shown above, and ends with its matching brace later in the manifest, and shown below.

The highlighted part of the manifest is the public key for this assembly. This public key can also be seen using the sn.exe tool, as follows:

C:\> sn -Tp C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll echo Not strong named: %1
Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Public key is 002400000480000094000000060200000024000052534131000400000100010007d1fa57c4aed9 f0a32e84aa0faefd0de9e8fd6aec8f87fb03766c834c99921eb23be79ad9d5dcc1dd9ad2361321 02900b723cf980957fc4e177108fc607774f29e8320e92ea05ece4e821c0a5efe8f1645c4c0c93 c1ab99285d622caa652c1dfad63d745d6f2de5f17e5eaf0fc4963d261c8a12436518206dc09334 4d5ad293
Public key token is b03f5f7f11d50a3a

Note that the Public key in the output from sn.exe matches the highlighted public key in the image immediately above it (of course you should ignore the spaces between pairs of digits in the screen shot).

If an assembly is not strongly named, the Public key will be missing from the manifest and will not be displayed by sn -Tp command.

Since IL DASM comes with both Visual Studio and with the .NET SDK, it is already on the desktop for most .NET Developers, and is therefore sometimes the handiest tool. The third option, .NET Reflector, is a third-party tool, though one adopted by many .NET Developers due to its awesomeness. Reflector conveniently shows more details about the strong name.

Approach #3: Viewing Strong Name Details with Reflector

You can load an assembly in the free version RedGate’s .NET Reflector and quickly see the strong name details – or lack thereof for non-strong named assemblies. In the image below, see at the bottom where the strong name string is highlighted. Note that the strong name has five parts (though the Culture is optional):

  1. Simple Name or Assembly name without the “.dll” extension (“System.Data” in case of assembly “System.Data.dll”)
  2. Assembly version (“” in case of “System.Data.dll”)
  3. Culture (“neutral” in case of “System.Data.dll”, but might be “en-us” for US English, or one of many others)
  4. Public Key or PublicKeyToken (public part of the cryptographic public/private key pair used to strong name the assembly, “b77a5c561934e089” in case of “System.Data.dll”)
  5. Processor Architecture – Defines the assembly’s format, such as MSIL (intermediate language) or x86 (binary for Intel x86 processors)

Using Reflector to show strong name

In the next image, see at the bottom where the LACK OF complete name string is highlighted; this assembly does not have a strong name to display, so “Name” field includes a null value for PublicKeyToken. (Note that in the real world, Spring.Core.dll is in fact released as strongly named by the good folks on the Spring.NET project; the screen shot below was done on a non-production version of that DLL.)

Reflector shows missing strong name

While you are at it… make Reflector the default program for “launching” assemblies (actually would need to be for all files ending in the .DLL extension, but Reflector is smart enough to not choke on non-.NET assemblies).

Approach #4: (Bonus!) Viewing Strong Name with Windows Explorer

This post promised three ways to tell if a .NET Assembly has a strong name – but here is a bonus 4th way. Windows Explorer will not show you the strong name characteristics of an assembly, with one exception – for assemblies in the Global Assembly Cache (GAC), strong name data is included in the Properties dialog. If  you are examining the GAC, this can be handy.

Of course, if an assembly is in the GAC at all, it is strongly named by definition; assemblies are required by .NET to be strongly named to be allowed in the GAC.

Strong Naming for Silverlight

Silverlight also has support for strongly named assemblies, which is needed for the Cached Assembly Feature introduced in Silverlight 3.0.

(Silverlight 4 also introduces supports for digital signatures on XAP files, created by signtool.exe, which are validated by the Silverlight runtime for out-of-browser (OOB) applications running with elevated trust.)

Strongly Name Assembly != Digitally Signed Assembly

Strong Names and Digital Signatures are Orthogonal Concerns – Almost

Strongly Naming and Digitally Signing are largely orthogonal concerns. They have different purposes, different tools, and the digital certificates may come from different sources (for publicly distributed binaries, the certs for Digital Signing usually will come from a PKI source, though that is not essential for the Strong Naming certs).

The only dependency among them is that if the Assembly is to be Strongly Named, then the Strong Naming step has to happen before the Digital Signing step.

How do I check whether an assembly is Digitally Signed? You can run the following command to determine whether assembly “foo.dll” is digitally signed:

signtool verify /pa foo.dll

If you want to see the hash – for example, to compare with another assembly’s hash – then you can view it using the following command sequence:

signtool verify /v /pa /ph foo.dll | find "Hash"

Of course, you can use sn.exe and signtool.exe together (one after another) to examine an assembly to ascertain both whether it is strongly named and whether it has been digitally signed.

Strong Names are NOT for Security!

Finally, a word of caution… Strong names are about versioning, not about security. Strong names are more about avoiding DLL Hell (which is largely an accidental concern) than about avoiding hackers (which is deliberate). While a strong name may help alert you to tampering, realize that strong names can be hacked, and Microsoft emphasizes that  strong-named assemblies do not give the same level of trust as digitally signing:

Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate.

Consider digitally signing your .NET assemblies if it is important to you or your customers that the origin of the assemblies be traceable and verifiable. One source of digital certificates that can be used for Digitally Signing assemblies is Verisign which has Authenticode Certificates.

See also the response to this comment for more details.