I am using iText to apply digital signatures in PDF. The digitally signed PDF is showing message like "the validity of the document certification is unknown. The author could not be verified.At least one signature has problems." at the top.
When I add the certificate to my trust identities which is used to create signed PDF, then the generated signed PDF shows "Signed and all signatures are valid".
Is it possible to fix this by without adding certificate to trusted identities?
Thanks in advance.
There are two reasons for the message to be displayed.
First, it's that you used self-signed certificate or other certificate, whose certificate chain doesn't end with the root certificate, trusted by validating application.
Second is when the signature parameters are not set right and Reader doesn't know that it needs to look for certificates in Windows certificate store. I don't know how to specify what I mean in iText - in our SecureBlackbox there's a property for this.
Please read https://itextpdf.com/book/digitalsignatures
Section 3.4 is named "How to get a green check mark."
The short version: if you want a PDF that shows a green check mark without having to install a root certificate manually, you need at least a private key that is stored on a physical device such as a Hardware Security Module, a USB token or a smart card.
Do you have such a key? Did you ask your CA for CDS or AATL certificate?
Re: Is it possible to fix this by without adding certificate to trusted identities?
Answer: no, unless you switch to a digital signature cert that was granted by a Certificate Authority trusted by Adobe.
This is an on-going issue with Adobe since Adobe Reader doesn't trust the CA's in the operating system. -- Instead, Adobe has their own list.
So either:
You get a personal cert from one of the companies on the Adobe list.
You publish your organization's root certificate on your website and provide instructions to recipients on how to tell Adobe to trust you. (Your organization can have just one member if you wish.) See below for more on this.
You tell your recipients how to click on the Adobe signature toolbar to inspect the details of the signing cert (and ignore the scary default warnings from Adobe).
In the wet-signature world, there are cases where you simply sign something, and other cases where you need to provide a copy of your government issued identity document. Unfortunately, in the current digital signature world, it's as if every signature needs to be accompanied by a copy of your driver's license. And that is simply not reality.
A common and successful answer is to publish your organization's root cert for all of the organization's signers. See Apple and Wells Fargo examples.
You can publish your root cert on an SSL-protected page with a cert from a trusted CA. That will enable a business partner to feel secure about trusting that your org's root cert is really from your org.
Related
I want to sign my driver, and I've taken a look to MSDN, and seen this: https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
They say:
If you don’t have an approved EV code signing certificate, you can buy one from one of the certificate authorities below.
Does that mean I should only buy EV code signing certificate to sign my driver, or regular one can be enough as well? What are the bad/good sides? Thanks.
Yes you need an EV certificate, as stated in the link you shared:
Microsoft requires an extended validation (EV) code signing certificates from partners enrolled and authorized for Kernel Mode Code Signing as part of the Microsoft Trusted Root Certificate Program.
Tim Roberts answer on social MSDN might clarify the process:
You can get Microsoft's signature in two ways: by running the WHQL tests and submitting the test results, or by submitting your driver package for attestation signing. Both of those things require that you submit your driver through the "developer hardware dashboard". The problem is that creating a "developer hardware dashboard" account requires an EV certificate.
For fun, I recently build a e-signature web app to allow users to add a handwritten signature to PDF (IE signing a TOS agreement).
It only took a couple minutes of research to realize my method of just added a written signature image to a PDF probably wouldn't hold up very well in a legal dispute.
A cryptographic digital signature is needed to verify the identity of the signee as well as ensure the document has not been altered since signing.
It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
I found this marketing heavy explanation where it says that they are considered a trusted CA themselves.
Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Even that you just need a link to a document envelope to sign (in most cases), this doesn't seem very meaningful.
UPDATE
Looks like you can "verify" signatures using acrobat reader to see the details. I opened up a PDF that I recently signed on Docusign and it appears that docusign is the signing identity?
Maybe I'm confusing "adding an e-signature" with "digitally signing", but shouldn't I be the Signed By __ identify?
Re: It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
Answer: DocuSign enables three different types of electronic signatures:
Simple Electronic Signatures (SES) are legal in the US and other common law countries for many purposes. They don't require a digital cert from the signer.
Advanced Electronic Signatures (AES) are a digital signature which provides a guarantee that the signer was identified by a digital cert and that the signed document has not been changed since it was signed. This type of signature is required for some purposes in common law countries (like the US) and for many purposes in civil law countries.
Qualified Electronic Signatures (QES) are like AES signatures but the signer cert is granted by a company that is authorized directly or indirectly by a government authority.
How it works
If the DocuSign signature is an SES signature then no signer cert is needed. And yes, these types of signatures are valid and legal for most any type of transaction in the US. See a lawyer for details on whether your transaction type can use this type of eSignature or not. Here is a summary of the law for the US.
For these types of signatures, when you download the signed document from DocuSign, the downloaded document is digitally signed (using an AES signature) by the company DocuSign. The DocuSign AES signature assures you that the document is the same as the document that was signed by one or more signers who used SES via DocuSign.
For AES signatures via DocuSign, the signer can use a cert that is issued to them by DocuSign. Or the signer can use a cert issued to them by their associated company/organization.
For QES signatures via DocuSign, the signer's cert comes from a qualified trust provider.
Re: Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Yes, for AES signatures, DocuSign can issue a cert to a signer. But that is not what happened in your example screenshot. In your screenshot, DocuSign enabled the signer to use a SES eSignature. DocuSign then provided an AES signature to guarantee to any relying party that the document was SES signed via DocuSign.
I am currently using the latest version of iText and using the example from the Digital Signing White Paper by Bruno Lowagie.
When I sign a PDF and view it within Adobe Reader the Certificate Chain is not shown and the Signer cannot be validated. What do I need to do in order to include the Certificate Chain with the Signature so the Signature is automatically validated by Adobe?
The certificate comes from Entrust..which is a member of the Adobe AATL program. So I am expecting the Signature to be automatically verified without me having to change trust settings within Adobe reader.
The iText software does not add the intermediate certificate so the chain of trust is broken. Entrust is a member of aatl, but only sells cds certificates
I am trying to use iText to specify a certification signature for Pdf documents that will automatically be verified (blue ribbon) within Adobe Reader. In order for this to occur, the certificate used for signing must be recognized by Adobe as tying to a root certificate of an AATL member. All AATL Certificate Authorities seem to deliver their certificates on a SafeNet USB Token. The example Bruno gives in his "Digital Signatures" white paper concerning USB Tokens shows the user being prompted for a password. Having a user specify a password isnt' going to work in my situation. Is there anyway to pass the password (PIN) with the call to a SafeNet USB Token?
Please read my white paper once more. In this paper, I'm showing different ways to sign a document with a USB token. When you use MSCAPI, it's evident that the user is prompted for a password because that's how it's implemented in the Windows OS. However, I also wrote an example that uses PKCS#11. In this example, the password is fetched from a properties file; the user isn't prompted for it.
Can 3rd party application access iPhone's keychain in order to add X509 certificate to it? If yes, how can it be done?
If not, can it access keychain just to read certificates from it?
Basically, what I need is:
1) my application needs to access https site which uses certificate not signed by any trusted CA. when trying to connect via https, I get an exception.
2) it would be great If I could programmatically add the root's certificate to the keychain; it would be sufficient if the user could access the site via Safari, accept its certificate, and then access the site using my application.
So far, I've been using the following interface to surpass https:
#interface NSURLRequest (DummyInterface)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host;
+ (void)setAllowsAnyHTTPSCertificate:(BOOL)allow forHost:(NSString*)host;
#end
but this is not exactly what I want.
Any suggestions?
This Apple document should document enough stuff to permit adding self-signed certificate (or a self-signed certificate authority) into the keychain, and make it trusted. I didn't test it, though. Source
See also the top answer on this question. It, however, doesn't seem to actually verify the validity of the certificate. Cocoanetics has also documented how to use NSURLConnection with self-signed certificates, and similarly also doesn't seem to verify the validity.
So, you almost certainly want to follow Apple's instructions. The "Extracting and Evaluating an Identity From a *.P12 file" section appears to contain a complete example on how to import a certificate, even one protected with a passphrase.
Combine that with "AdvancedURLConnections" sample code and the ServerTrustChallengeHandler class and you should be good to go.
Here's also a more complete example by Vanja Komadinović.