EldoS | Feel safer!

Software components for data protection, secure storage and transfer

I am getting an 8219 error in a .net wcf project running under IIS

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
Posted: 07/06/2015 04:27:29
by Mustafa KARADAYI (Basic support level)
Joined: 07/06/2015
Posts: 2

I am getting following error when trying to sign a pdf document in a .net wcf project running under IIS. When i am using the same code block in a console or wpf application everything is working fine.

What am i doing wrong or how can i work around this?

1- My signing process uses smartcard-stored certificate.
2- We have tried the code block either in x86 or x64 mode. But, the result is same.

Signing failed (error 8219 )
SBPDFSecurity.EElPDFPublicKeySecurityHandlerPKCS7Error: Signing failed (error 8219 )
at SBPDFSecurity.TElPDFPublicKeySecurityHandler.SignHashPKCS7(Byte[] Hash, Int32 StartIndex, Int32 Count, Boolean AsyncMode)
at SBPDFSecurity.TElPDFPublicKeySecurityHandler.SignHash(Byte[] Hash, Int32 StartIndex, Int32 Count)
at SBPDF.TElPDFDocument.InsertActualSignatureInformation(Boolean IncrementalUpdate)
at SBPDF.TElPDFDocument.Close(Boolean Save)
at .....
Posted: 07/06/2015 04:37:51
by Eugene Mayevski (EldoS Corp.)

Thank you for contacting us.

The most likely cause of the problem is that the certificate is not accessible from under the user account under which the service code runs. The details depend on how exactly the certificate is accessed (via CryptoAPI or PKCS#11) and other factors which you have not specified.

I’ve noticed there is no license ticket linked to your user account on EldoS site. Support is provided to customers with the linked license tickets. You will find your license ticket together with all the details about how to use it in the registration e-mail that we’ve sent to you upon the purchase.

If you are evaluating the product and don't have a license yet, please let us know and then you can have support according to Basic support level. Basic support level includes answering basic technical questions that appear during product evaluation period.

Sincerely yours
Eugene Mayevski
Posted: 07/06/2015 07:05:54
by Mustafa KARADAYI (Basic support level)
Joined: 07/06/2015
Posts: 2

Thank you for quick reply,

The company which i work has the license ticket. I will be contacting you by company's account for the detailed answer.

Thanks in advance.
Posted: 07/06/2015 10:52:31
by Eugene Mayevski (EldoS Corp.)

Please see the FAQ article on https://www.eldos.com/security/articles/8181.php -- I've just prepared this article as an extended answer to your question.

Sincerely yours
Eugene Mayevski
Posted: 07/08/2015 07:10:21
by Kurumsal Mimari (Priority Standard support level)
Joined: 07/07/2015
Posts: 3


I've read the article and i tried to use PKCS#11 interface. But, it retuned me a license error;

"Your security license key doesn't enable requested functionality. Please check if you have a license for the components that you are trying to use."

Which license do we need to use PKCS#11 interface?
Posted: 07/08/2015 08:07:35
by Eugene Mayevski (EldoS Corp.)

PKCS#11 interface requires a license for PKIBlackbox or any other package which includes full PKIBlacbox (i.e. Data Security, Standard, Professional).

I welcome you to consider other options before going for PKCS#11. While PKCS#11 lets you address some issues of CryptoAPI, this is a different interface with its own quirks and complexities.

Sincerely yours
Eugene Mayevski
Posted: 07/09/2015 04:03:34
by Kurumsal Mimari (Priority Standard support level)
Joined: 07/07/2015
Posts: 3

I've already tried to make my code impersonate as a local user;
Although, It was able to access the certificate and the private key, I'm getting the same error which is 'Signing failed (error 8219)'.
Posted: 07/09/2015 04:59:20
by Ken Ivanov (EldoS Corp.)

Hi Mehmet,

There are two typical reasons for the issue in scenarios like yours, both of which are more or less of the same probability.

The first possible reason is in the difference in access policies applied to your console application and to the IIS service by the system. A desktop application, be it a GUI or a console one, is the least restricted permissions-wise and can do a lot more with the system comparing to service applications (especially comparing to IIS, which is a restricted service by itself). Particularly, lowered access permissions might restrict the IIS process from accessing certain certificate locations.

As you are not in control of how and where the certificate is installed (it is mapped to the system store by the device driver), the set of actions you might try here is quite limited. What I would suggest is

1. Try to play with the way the TElWinCertStorage object is used. Please try (a) setting ReadOnly to true (you may wish to always do it unless you need to alter the contents of the device), and (b) setting AccessType to atCurrentService, atCurrentUser, atLocalMachine, atServices (please try each one), and check whether the certificate can be used in any of the configurations.

2. Check the IIS access policy. It might be that the driver requires certain permissions to perform its operations which are not available for the IIS process. The easiest way would probably be enabling all permissions and checking if the problem is gone; then switching off permissions one-by-one trying to identify the one which is causing the problem. Launching IIS under a different user account, with administrative permissions, might also help to establish whether the problem is permissions-related.

The second possible reason is a wrong target platform of the application. Certain token vendors only implement the CSP layer for their devices only for one particular target (x86 or x64), making the devices only usable for applications with that particular target. While your IIS module obviously strictly depends on the target the IIS binary was compiled for, you might still try compiling your module for the exact target ("x86" or "x64", but not "AnyCPU") and checking if that helps.

Although, It was able to access the certificate and the private key

How exactly did you check that the private key is accessible? Did you use the certificate object's PrivateKeyExists property?


Posted: 07/10/2015 08:18:04
by Kurumsal Mimari (Priority Standard support level)
Joined: 07/07/2015
Posts: 3

How exactly did you check that the private key is accessible? Did you use the certificate object's PrivateKeyExists property?

Yes, I used PrivateKeyExists property and it's value was true. But, after you asked me the question above, I made a debug again and encountered the situation below;

First, I took the certificate from wincertstore by using TElWinCertStorage. Then Converted it to X509Certificate2 to see PrivateKey property. And, there was an exception on PrivateKey property ''certificate.PrivateKey' threw an exception of type 'System.Security.Cryptography.CryptographicException''
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.



Topic viewed 2400 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!