Some days ago I got the security token project back to the surface (from the deepest part of my repository) to use in in another current project. Unfortunately I got an error message as I started the project for the first time. I didn't know where it came from, so I went through the code step-by-step. Fascinated I recognized that it didn't appear again. I reloaded the page several times, but everything seemed to work fine. Because of this I thought it would have been a cache problem and forgot it.

Some hours later I had deleted my cookies and tried to issue myself a new token - but there the error was again - and again it disappeared during the step-by-step debugging.

Because I couldn't find a specific reason for this I spread several breakpoints all over the code and just hopped from one to the next to narrow the place of the exception. As I finally found the place in the code, I got the following error message:

"The SamlToken is not time valid. The current time "5/14/2008 11:29:21 AM" is outside the Effective "5/14/2008 11:29:59 AM" and Expiration "14.06.2008 11:29:59" time of the token.

What happened? First I guessed that there could be a bug in the calculation of the date, until I recognized: The token was valid some seconds AFTER the issuing. But why? Could that be a build in method?

After some research in the internet I found someone who had the same problem. He already had answered the question for himself: "I think I should correct the time of the server" ... right ... there was a time difference of 30 seconds between my PC and the dev-server I used - that has been the reason why the token was not YET valid as I it was issued to me - and this was the reason why I couldn't find it as I went through the code step-by-step, because I needed a longer time to step through than the differnce between both machines.

Because I hit that error today for the second time (the first time appeared some weeks ago), I thought I just should write it down to not forget it again:

If you get the error messages "Bad Key" or "Invalid handle" in relation to any kind of "System.Security.Cryptography.CryptographicException", you should at first check the write/read-permission of the private-key-file of the certificate - and in the second step, if it contains all required values for our intention (Because you can't do everything with every certificate).

My problem: I tried to use an X.509 certificate to sign a Saml-token. Foolishly there were errors on several places, which a catch-block (in combination with a not working logger) hid, so that I needed a lot of time to search for the reason.

Both errors appeared while serializing the token.

Two problems and their solution:

Problem 1 - "Invalid handle": This error appeared, if the script couldn't access the private-key file of the certificate. The user "NETWORK SERVICE" needs at least read-permission for this file.

How can I find the private-key file? There's a nice tool collection, created by Microsoft, called the WSE "Web Service Enhancements"... the version, which is, I guess, the current one, is 3.0 - even if most of the results show 2.0, if you search for them with Google.

This collection contains a tool named "WSE X.509 Certificate Tool", with which you can simply select the right values in the two dropdown lists and open a filtered list of all found certificates by hitting the button. As soon as you open a certificate, you can see all information about it. This is the view of one of my test-certificates, which I created myself.

At the bottom of the window, you can find a button labeled "View Private Key File Properties". If you click that button, it displays the normal Windows-file dialog for the specified private-key file. In the tab "Security" you can now set the permissions for that file (in our case "NETWORK SERVICE"). As soon as the script is able to read the file, the "invalid handle" message disappears. 

Problem 2 - "Bad key": Who is able to read, has an advantage (german saying):

As soon as the one input field (Image 1) is replaced with three single input fields (Image 2), the description text on the right changes. It sais: "If the extension is not present, three values will be shown[...]". If I would have read that the first time I tried it, I would have saved much time, because the certificate I bough simply hasn't had the so callend "Subject Key Identifier", which is required for signing the token. As soon as the certificate contains the SKI, you won't get the error message anymore.

You can find the WSE tools on the Microsoft-download-page.

One last hint I got for you: If you want to check your software against certificates, you can create your own certificates, containing all combinations of rights. There's a nice tool from EldoS which is called "Crypto4™ PKI". It's commercial, but a 30-day trial version can also create nice certificates (for a specific time) ;-).