EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Chain validation failed when signing document from ASP.NET MVC

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
Posted: 11/25/2015 08:27:48
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

I am trying to sign a pdf document that resides on IIS server from local machine where user is working. I don't need to download document from the server (it can stay there), so I am just uploading PFX certificate to server and trying to sign a document directly on the server. For that task I am using a class library which was developed using SBB and which is working. However when I try to sign it I get error: Chain validation failed. I think that I understand where is the problem. Problem is probably that I don't have on IIS machine under DefaultPoolAccount (under which app is running) imported root and intermediate certificates, but I don't know how to do it. I saw your recommendation to use WinHttpCertCfg.exe tool but when I tried it I get error:

C:\Program Files (x86)\Windows Resource Kits\Tools>WinHttpCertCfg.exe -g -c LOCAL_MACHINE\ROOT -s "Test CA Root" -a "DefaultAppPool"
Microsoft ® WinHTTP Certificate Configuration Tool
Copyright © Microsoft Corporation 2001.

Matching certificate:
CN=Test CA Root
CN=Public Key Services

Error: Access was not successfully obtained for the private key.
This can only be done by the user who installed the certificate.

It might be that I am totally on the wrong track. Please help me, what am I doing wrong?
Posted: 11/25/2015 08:37:21
by Eugene Mayevski (Team)

Thank you for the interesting question.

First, A couple of general notes:

1) I'd like to note that uploading user's PFX to the server is a very limited approach. While it can work for simple scenarios, you will come over different obstacles, such as problems with collecting revocation information.

2) Sending a PFX to the server is a straight way to security breaches.

The proper approach would be to use distributed signing using our Distributed Cryptography add-on. You can use browser-based signing on the client or you can compile the corresponding classes right into your client application's code.

Now about your problem.

It is not clear from your message, how validation is involved into your signing process. If you could describe, what you are doing, in more details, we would be able to understand how to approach the problem properly.

In general we have a couple of how-to articles in the knowledgebase dedicated to proper validation of certificates and these articles include detailed instructions on diagnostics of validation errors.

Sincerely yours
Eugene Mayevski
Posted: 11/25/2015 09:53:50
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

The thing is that my class library which I am using for signing in desktop solutions is signing PDF documents with PAdES, Office and XML documents with XAdES and rest of the formats with CAdES. Concretely in this case I wanted to sign PDF, so I am using TElPDFAdvancedPublicKeySecurityHandler, as a signer handler. In setting up it, I am using two events:

  • OnCertValidatorPrepared
  • OnCertValidatorFinished

In OnCertValidatorPrepared, I am trying to get CA certificate of signing certificate to add it to trusted certificates with method AddTrustedCertificates of class TElX509CertificateValidator. But I don't find CA certificate. Hence, I think, I get the error.
However if your opinion that this is not right approach, I will change it. Anyway this is just first version where I thought it is easier to do with a certificate from file, but my final version has to have document signing with signing from smart card (so any way I will need some client side magic to get certificates from smart card). What is exactly the problem in sending certificate over wire in my scenario, where I don't need document on client side (let's assume will do it with https)?
Posted: 11/25/2015 10:11:49
by Eugene Mayevski (Team)

Transfer of the certificates to the server is not safe because the server itself can be compromised. It's better to keep certificates on the client side.

If you plan to use certificates on smartcards, you won't be able to retrieve the private keys from smart cards, so you have two options there: either transfer the document to the client side and perform everything in place, or use our Distributed Cryptography add-on. The second approach is preferred when you don't have a client-side application for whatever reason.

No matter what approach you choose (or stay with your current approach for a while), collection of the revocation information is needed and you can face validation errors during such collection. I welcome you to read and follow the instructions in https://www.eldos.com/security/articles/7545.php ,
https://www.eldos.com/security/articles/7639.php and https://www.eldos.com/security/articles/8115.php . All these articles contain information relevant to what you are doing.

Sincerely yours
Eugene Mayevski
Posted: 11/25/2015 10:27:55
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Ok, thanks for explanation. I do not stay with approach which is wrong by expert's opinion :)

I have ASP.NET MVC application and I want to enable in it documents signing with certificates from smart card, as well as from a file. Do you think my case suits for Distributed Cryptography? Do I have with my current licence right for using Distributed Cryptography, or I have to buy that?
Posted: 11/25/2015 10:54:17
by Eugene Mayevski (Team)

As I said, use of DC add-on is not needed if you can download the data to the client and have an application to do signing there.

If you prefer to use distributed signing, I welcome you to review the Distributed Cryptography Add-on.

As for the license, I'll move your question to the helpdesk.

Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.



Topic viewed 1823 times

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


Back to top

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

Got it!