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
Related
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
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.
I am learning about Azure Key Vault, and one of the scenarios it supports is certificate authentication, which you can read about here.
The samples do a great job of explaining how to make a self-signed certificate for local testing, which I have gotten to work without an issue. My question now is, how do I go about making a certificate for production deployments? Do I purchase this from a service somewhere? If so, what type of certificate do I need, exactly?
Unfortunately, there is no documentation anywhere that I could find in Azure Key Vault that outlines how to make (or what is expected/assumed) in a production-level certificate.
I basically have a few requirements/expectations based on my research/investigation so far:
I would like to use a trusted, external service (CA?) to purchase the certificate from.
The cheaper the certificate the better. :)
I would like to be able to create a certificate with custom data extensions.
In addition to my requirements, I have a specific question in regards to the certificate: What type of certificate do I need? Is this a server authentication certificate? Or a client authentication certificate? Or... ?
I have spent the past hour going through several SSL certificate providers, but none of them really could give me a great answer for the type of certificate I am looking for (when I provided the link to Azure certificate above to them). So, I decided to do what I should have done in the first place, and put my question up here to the esteemed community. :)
Thanks in advance for any assistance.
If you want the cert for SSL you want to get a Server Authentication certificate (it proves that the server, ie your site, is who it claims to be).
You can buy it from any trusted service and upload it to Azure Key Vault. Just google "buy ssl certificate". I think you can get one for as little as $30 if I remember correctly.
You can use Key Vault to enroll for certificate from public CAs such as DigiCert and GlobalSign. Look at the "Enroll programmatically from Public CA" section in https://blogs.technet.microsoft.com/kv/2016/09/26/get-started-with-azure-key-vault-certificates/
You can use the Key Vault REST API to programmatically enroll for certificates -https://learn.microsoft.com/en-us/rest/api/keyvault/createcertificate
The certificate policy allows for some customization like specifying which KeyUsage and EKUs you want in your certificate.
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.