The distrib.xml document (a serialized state which was obtained from the InitiateAsyncSign() call) is actually a *signing request*. After obtaining the request from InitiateAsyncSign() you should pass it to the DC server for actual signing. DC server will respond you with another state, a *signing response*. Signing response is what you should pass to the CompleteAsyncSign() method. What you are doing now is passing the signing request to CompleteAsyncSign(), and this has no sense, as CompleteAsyncSign() needs the result of signing operation.

I suggest you to have a look at the DC PDF signer sample for WinAzure. Though this one has little relation to CMS signing, it demonstrates main concepts of DC subsystem. MainWebRole fulfills the client-side part of the system, while MainWorkerRole is a DC server. In fact, the implementation of DC server will be mainly the same independently of what exactly (CMS, PDF, XML) is signed on the client.

Why MainWebRole has an certificate? I hoped to find a certificate (and private key) only on the MainWorkerRole.

I have a document on a web server and I have a client machine with a browser to make the signatures of documents. The signer's certificate is only in the client machine. I want to use the distributed signature to sign the document that is on the web server on the client machine without sending it to the client and without the signer's certificate is in my web server.
In the ELDOS examples that I found, certificates have been used in the web server and the client machine.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.