We are working on optimizing the digital signing process using the signtool.exe digest options. So far the workflow looks like this:
Create the digest on the client: signtool.exe sign /f cert /fd sha256 /dg . MyFile.dll
Send MyFile.dll.dig digest to our signing server.
Sign digest on the signing server: signtool.exe sign /f cert /fd sha256 /ds MyFile.dll.dig
Send the signature MyFile.dll.dig.signed back to the client.
Create signature on the client: signtool.exe sign /di .MyFile.dll
Add a timestamp on the client: signtool.exe timestamp /tr http://some_timestamp_server /td sha256 MyFile.dll
Is there a way to perform timestamping on the signing server?
Is there a way to perform timestamping on the signing server?
No, not without transferring the entire file to your signing server. The timestamping is an operation applied directly to the file itself, so the file must exist locally. Your remote signing service only works because only the digest needs to be signed, not the full binary. However, as you pointed out you still need to ingest the signed digest locally using the /di signtool option.
What you can do is create a custom tool to programmatically sign and timestamp a file according to your requirements. See this Microsoft article for how to use SignerSignEx2 function which supports timestamping.
https://learn.microsoft.com/en-us/windows/win32/appxpkg/how-to-programmatically-sign-a-package?redirectedfrom=MSDN
You've may have already seen this, but I would also look at the AzureSignTool repo which uses the undocumented SignerSignEx3 function to perform the signing using a callback. You could reasonably replace the Azure functionality with a call to some other custom signing service.
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
I have created a small windows executable and I need to digitally sign before delivering. The main reason is to replace "Unknown Publisher" line with company name in UAC dialog.
I found the tool (signtool) and commands to sign the application. The one core requirement is a valid digital certificate. As we already have digital certificate issued for our company's website so I tried to use that certificate for signing, but I am getting an error 0 certs were left.
Based on my research, this error occurs if:
Certificate is expired
Certificate is invalid
cmd is not running as Administrator
But this is not the case here. As certificate is not expired and I installed it on my system and it has "Certificate is OK" status, and I am running cmd as administrator. So I have no clue, what's wrong.
Questions:
Does the regular SSL certificate can be used for signing executables or do they have some different kind of certificates for this purpose?
What is the appropriate way to convert .pfx certificate from .cer and .key file? (the most common method seems to be pvk2pfx but I didn't found a way to convert .key into .pvk so I used openssl.exe)
Is there any limit for signing executable from a certificate? (e.g. this certificate can be used for signing 5 applications only)
Referring to the Azure keyvault Sign API at https://learn.microsoft.com/en-us/rest/api/keyvault/sign/sign. Its not clear if the "value" which is string (in request and response both), how the API expects the encoding for binary strings like digest and how the response has this 'value' encoded? Is this in base64? If so, Azure has any difference in base64? Any sample code showing this REST API request/response processing?
Looking for help in understanding how (and if) we can use the ‘Sign’ API to sign the X509 digital certificate.If we generate or upload the Keys (private key – corresponding to the root CA cert), can that key be used to sign a digital certificates issued by this CA. If so, what would be the right steps to do this. In my understanding, take the digest of the x509->cert_info, encode this digest in base64 and call Azure 'sign' API. Once we have the response, append the signature to X509 certificate (that was being signed i.e. x509->signature with this signature). Would be great if you could share code example.
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 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.