I am using the docusign api to generate envelopes dynamically. Is it possible to indicate when generating an envelope that the signers must use a digital certificate that they have installed on their computers to validate their signature?
Thanks.
You can use certificates if they're from valid TSPs. TSPS provide an interface for sending and signing documents online and work with the appropriate Certificate Authorities to provide trusted digital certificates.
Read more about Standard Based Signatures
Related
Context
I'm using mTLS to secure Docusign Webhooks (Docusign Connect Service). I'm able to make a successful mTLS connection to get certificate fingerprint, according to the documentation.
The next suggested step is to do access control by validating the certificate fingerprint and possibly the Distinguished Name (DN) but I'm confused what should the correct way to do so.
Questions
How do we know which client certificate is going to be sent by DocuSign to our listener in live environment (theoretically can be one of these and which logic is used to determine which one is sent? Should we validate which certification is sent by the DN (e.g. connect.docusign.net)?
What information should we validate from the certificate message? The fingerprint, DN, both or more?
With the above, how can we know all possible fingerprints to validate from server side, assuming different webhooks messages can send different client certificates? Should we compute the fingerprint of all public connect certificates to get a full list?
What is the best way to handle expirations of client certificates?
Re:
Q. How do we know which client certificate is going to be sent by DocuSign to our listener in live environment (theoretically can be one of these and which logic is used to determine which one is sent? Should we validate which certification is sent by the DN (e.g. connect.docusign.net)?
A. Best is to validate based on the certificate's fingerprint matching a fingerprint of one of the expected certificates. DocuSign uses different certificates depending on the platform. But there's a limited set of certs used, so it should not be a big deal to check to see if the offered cert matches one of the expected certs.
Q. What information should we validate from the certificate message? The fingerprint, DN, both or more?
A. I'd recommend the fingerprint since it is more specific than the DN. With the DN, you're trusting the CAs to not issue a cert with a DocuSign DN to a bad guy. It should never happen but it has in the past (not to DocuSign though). See Rogue certificates
Q. With the above, how can we know all possible fingerprints to validate from server side, assuming different webhooks messages can send different client certificates? Should we compute the fingerprint of all public connect certificates to get a full list?
A. DocuSign uses a limited set of five certificates for webhook notifications, see the list on the trust center in the Connect Certificates section. Checking the incoming certificate against five or ten (see below) fingerprints is not a big deal.
Q. What is the best way to handle expirations of client certificates?
A. When the new certificates are announced, compute their fingerprints and add them to your system.
Then test by switching your DocuSign account to use the new certificates. Once the test succeeds, you can delete the fingerprints of the old certs.
We are having a unique requirement where in we have to include the signing certificate in signed pay load. I'm looking for equivalent of CmsSigner class of .NET where I will be able to add the signing certificate as well as certificate collection to and then sign the data with the same and also include these certificate collection in signed pay load. If some one knows of way to achieve this in Node. js.
I have tried using the crypto module of Node.js for signing. Unfortunately it does not have the capability to include the signing certificate in the signed pay load.
So please help with your suggestions
Thanks and regards
Venkatesh
I'm building a web application that builds a XML document based on the user input. After the doc is created, it needs to follow an approval path, e.g. a workflow, where several users "sign" the document. The signature from the user point of view is just checking a field and clickin "accept", but what I need is for the document to be digitally signed in each step, to
finally store it signed in a database.
What kind of devices/tools do I need to use? X.509 certificates on the client browser? Public/Private keys generated by the app? Any link to documentation will be appreciated.
Certificates are not normally generated by the application (since PKI is about trust, which is hierarchical in case of certificates). Users acquire certificates with private keys (let's say so for simplicity) and store them in the safe place or on hardware devices (smartcards, USB tokens).
Then those certificates are used to sign information. In case of web application you can either transfer the data itself to the client or send a hash of the data there, but in any case signing takes place on the client side (except rare cases where certificates are stored on central server and access to them is authorized by the client each time the certificate is used).
We offer components for distributed signing of data. This answer contains detailed description of how such signing works. You can use our solution or create your own, that will do the same.
I would Like to know which type of certificate do I need to get from a Certification Authority to Sign an XML Document (XML-DSIG) in .NET ? shold i get an SSL certificate?
We have a xml electronic invoice that we need to sign using a Digital Certificate.
Any thoughts?
No, it's not SSL. I guess Document Signing offer by GlobalSign will work for "regular" XML as well. Also, it can be that local authorities (either CA or those organizations that require or accept signed documents) issue some special certificates for your task.
I imported a third party CA issued PFX certificate using PFXImportCertStore. Upon successful importing, the PCERT_KEY_PROV_INFO_PROP_ID is set to the following values by default by the same call, PFXImportCertStore
Why is the dwKeySpec recognised as AT_KEYEXCHANGEkey type rather than AT_SIGNATURE?
Why is the pwszProvName set to Microsoft Base Cryptographic Provider v1.0?
The certificate in the first place was issued ONLY for Digital signing. But the key usage field indicates that the certificate can be used for Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0). Enhanced key usage indicates, Client Authentication and Secure Email? Has the CA has issued the certificate correctly? The front of the certificate shows the following message(screen shot below) which makes me to suspect that this certificate was not issued for digital singing? Am i thinking correctly or not?
4.Because of these issue, i am unable to sign data using CryptSignMessage. The internal call fails to acquire context to the private key for signing. Any suggestions on how i can get around this issue?
I am able to sign with a selfsigned PFX cert which i generated. Do you think that i could export the private key in to new container and set it property to AT_SIGNATURE and the csp provider Type to PROV_RSA_AES, as i require SHA256.
I am working with XP sp3.
Thanks
Answer 1: The key is automatically classified as AT_KEYEXCHANGE because, its usage is also to encrypt session key etc. ie Though my application's main purpose is to digitally sign data, the CA has defined the key usage policy to include encipher, which forces CryptoAPI to map the key type to AT_KEYEXCHANGE.
Answer 2: I ASSUME that it is a default csp in this machine, so...? Any better explanation, please
Answer 3: From many replies from guys in Crypto Google group, AT_KEYEXCHANGE key can also be used to sign data, provided your certificate's key usage allows you to do digital signing. It seems to be common practice for third party CA's to issue certificates that can be used for multiple purposes. So the third party CA has issued the certificate correctly.
Answer 4: I managed to sign data using CryptSignMessage with the same third party issued certificate. I changed the dwProvType in PCERT_KEY_PROV_INFO_PROP_ID to PROV_RSA_AES and passed in NULL for pwsProvName. This change is performed by using CertGetCertificateContextProperty first to get the properties and then using CertSetCertificateContextProperty to set the properties of your choice. This fixed the signing issue. Now i am able to sign with SHA256/RSA1024, AT_EXCHANGE key.