Chain of trust cannot be added in VBA code - vba

I received a .pfx Code Signing certificate from Sectigo CA.
After I installed it, I signed my VBA Code with said certificate.
When I open the file on a different computer, it can't be verified that it's signed and when I look into the certificate details, it doesn't display me the chain of trust like on the computer I signed it on.
Is there a way I can add the chain of trust to my vba code?

Related

Is it wrong to import a self-signed certificate to "Trusted Root Certification Authorities" store?

I have created a self-signed certificate to sign my program.
I noticed that importing the certificate using:
certutil.exe -addstore root "Tmp.crt"
Makes UAC warnings "more friendly" (showing the publisher name, without paying hundreds to Certificate Authorities.
My program is dedicated for a small group of people. Is it safe to create a prompt asking users if they want to install the certificate to the "Trusted Root Certification Authorities" store? Assuming they already trust the program enough to allow starting with administrative permissions.
If they import and trust your self-signed certificate, they are explicitly asked to trust you.
If you use a code signing certificate from an "official" (= paid-for) certificate authority, they are not asked to trust you explicitly, but they trust your certificate implicitly through that certificate authority. They have never been asked if they trust that authority, because it's trusted by the operating system for them.
As a consequence, I can't see how asking to trust your self-signed certificate would be more unsafe than relying on someone else's decision to trust a certificate authority. The only downside is that the user might be disconcerted by being asked something they are not usually asked.
You can increase security by making your program check the certificate it's been signed with to make sure it's indeed the one you self-signed.
It's not wrong but it could be unsafe if they are not getting your application from a trusted source. You could instead request a free certificate from the Let's Encrypt project. Here is a link to their getting started page:
Let's Encrypt Getting Started

Using a pfx file to sign and verify using signtool.exe

I am trying to sign one of my WIX EXEs using sign tool. When I create a certificate and install it to windows certificate store, I can easily verify the EXE using sign tool. But when I try to create a PFX file and sign it, it gets signed successfully. But when I try to verify it, it throws the below error.
SignTool Error: WinVerifyTrust returned error: 0x800B010A
A certificate chain could not be built to a trusted root authority.
Number of errors: 1
I tried using a certificate chain and signing using the commands mentioned in the answer of https://social.msdn.microsoft.com/Forums/sqlserver/en-US/da5d1aef-5dbc-4400-8972-fef4d7139d99/where-windows-sdk-tools-like-cert2spcexe-and-pvk2pfxexe-go?forum=windowssdk. But that results in the same error as well. My requirement is to sign and verify using a PFX file using signtool. I cannot use Windows Store. Any help would be much appreciated.
The method described in http://msdn.microsoft.com/en-us/library/ff699202.aspx creates a self signed test certificate. A self signed test certificate is not signed by a trusted 3rd party, so you get the error "A certificate chain could not be built to a trusted root authority." when trying to verify the file signed by the certificate.
If you want to fix the error you will need to obtain a code signing certificate from a certificate authority. Usually for a fee.
When you purchase a code signing certificate, the certifying authority takes certain steps to verify your identity. If those steps are passed, the certifying authority issues you a certificate signed by their private key. Their private key is kept secret. When you verify the signed file, the verification process extracts the code signature from the signed file and validates it against one of the known public keys provided by all of the certifying authorities.

Why do we need to install digital certificate?

The question may sound a bit stupid but I really want to know this.
When we download a file, say abc.exe, it is digitally signed with some digital certificate of some organisation. Why do we need to install that certificate? What is the use of it? What if we dont install it?
When I run certmgr.msc in my windows system, I see some certificates already installed. What do they mean?
If you get signed material, you may want to verify the signature.
Digital signatures usually are created using a private key and can be verified using the associated public key.
Certificates essentially are transport containers for public keys with some extra information. Thus, to verify signatures you usually need the certificate of the signer.
You install certificates to make them known to your system (to allow for signature verification) and to tell your system to trust material signed by the associated private key.
As having to install certificates by each and every party you want to trust is too much work, certificates can have hierarchies, some root certificate may be the issuer of multiple other certificates, and by trusting that root you implicitly trust those other certificates the root issued.
For more details you may want to ask on https://security.stackexchange.com/.
The RSA algorithm used for encryption is used for digital signatures.
Use of RSA for a signature is as under:
1. First, a message digest is calculated.
2. The private key is used to sign the digest of the message.
3. The signature is appended to the message and transmitted to the recipient.
4. The recipient calculates the digest of the received message.
5. Then, verifying the signature requires extracting the signature from the message
and using RSA on the signature with the public key.
6. If the result of the transformation and the newly calculated digest are equal, the signature is valid.

itext white paper on digital signatures: page 68: two certificates can be very confusing to users

0) I'm not sure if I'm reading the whitepaper correctly, there's a chapter on Certificate Authorities, so I assume that the white paper would teach me how to digitally sign a pdf. But page 68 appears to only show that the document is signed but it doesn't do "certify documents" are authentic.
I'm reading page 68 of this article
http://itextpdf.com/book/digitalsignatures
I want to also comment that the two signatures can be a source of confusion to anyone looking at the pdf. The first confusion MY end users will ask is:
a) why are there two certificates (I've read it and understand the reason why there's two certificates) where one says one thing but the other says another?
What's concerning is that Bruno Lowagie's certificate is marked as NOT trusted as a "sign documents or data" and pdf is NOT trusted for "Certify Documents" What I'm trying to say is, it's very confusing to end users when they click on the certificates and see that one is trusted and the other is not. Figure 3.3 vs. 3.4. page 68.
The certificates are aligned as such:
Cert Signing Authority <supp
Bruno Lowagie <bruno#low
Conversely, someone sent me a sample of a pdf that has only ONE certificate, and it says "Certified by [HIS COMPANY NAME]" then when you click on Show Signer's Certificate, on the left column you'll see the following:
Adobe Root CA
GlobalSign CA for Adobe
HIS COMPANY NAME
Here, you click though any of the above levels Adobe Root CA, GlobalSign CA for Adobe, and HIS COMPANY NAME; they ALL say certificate is trusted to "sign documents or data, certify documents." This consistency makes sense.
I have not played around with the code yet, but is it possible to use itext and make it look like what I see in my friend's sample pdf?
If I'm going to pay for the itext license, I want to make sure that I'm able to programmatically digitally sign the pdf with CA certificates and that the Trusts would ALL look consistent, which makes sense.
If there is only one certificate, you are confronted with a self-signed certificate. Self-signed certificates should never be used to sign a document. The only self-signed certificate that should be trusted is the root certificate of a Certificate Authority (e.g. the Adobe Root Certificate, the GlobalSign root certificate,...).
These certificates are kept in a vault under very high security. They are NEVER used to sign a document. They are used to issue intermediate certificates.
In your example, you mention the "Adobe Root CA". GlobalSign paid Adobe a lot of money for Adobe to use this certificate to issue the intermediate certificate "GlobalSign CA for Adobe". GlobalSign makes money using this certificate to issue certificates for companies who buy an HSM or a USB token (in case of a USB token, there's even one extra certificate in the certificate chain).
This is how it works. If you have read my whitepaper, you have missed the part where the concept of having a Certificate Authority (CA) is explained. If you would send me a signed document, and I would NOT see a certificate issued by a CA, I would NOT accept your document. I would demand that you either use a certificate under the Certified Document Services (CDS) with Adobe's certificate in the Root, or I would ask you to use a certificate of which the root certificate can be found in Adobe's Approved Trusted List (AATL).
If I would only see your company name in the certificate chain, I would NOT accept your document. Your allegation that I would be confused when I see Adobe's or GlobalSign's certificate is wrong. The opposite is true: I need to see a certificate from a CA before I can trust your signature.
Self-signed certificates will never automatically result in a green check mark. To get a green check mark automatically, you need a certificate that is issued by a CA. This CA should be a member of either CDS or AATL. This means that the certificate will need to meet or exceed FIPS 140-1 Level 2. This implies that you'll need to invest in either a Hardware Security Module (HSM) or a USB token.
You will not succeed in getting an automatically trusted "green check mark" signature using a software certificate (PKCS#12), not with iText, not with any other software.
HSM:
USB Token:

Signing PDF with a certificate in a certificate store

I want to sign a PDF with a certificate in a certificate store.
I am using iTextSharp and iSafePDF for singing PDFs, it works OK when I sign using a certificate stored as .p12 file. But I don't know how to use the library for signing with certificates obtained from a certificate store. I have an instance of System.Security.Cryptography.X509Certificate2, but the library uses a different object representation and I was not able to make it work. Can someone help?
OK, here is exactly what I was trying to find, the accompanying text is in Czech, but there is not much of it and the code that works is what matters.
Signing PDF using a certificate in the certification store