Why my Pdf certificate status "Revocation checks status were not perform"?
How to perform revocation check with iText7?
Do I need to do this before injecting .p7s into the Pdf?
Please read the message at the bottom of the dialog:
The selected certificate has errors: Not time valid
Most likely your certificate simply is beyond its validity, check it on the Summary or Details tab.
(The pdf you linked is incomplete.)
Related
As I can see, in Windows, the Digital Signature tab of an EXE file will show the Company Name, City Name, and Country Name of the company.
Is the user able to find the detailed address of the company from the signature? The situation is the same for OV and EV code signings?
Thank you.
Information appearing on the Digital Signature tab come from the 'Subject' field of the certificate.
This information is provided by the company when signing keys are generated.
Then, those keys are used to generate a Certificate signing request (CSR) who contains this information + public key.
This is this CSR who is transmitted to the certificate authority.
The certificate authority will then sign digitally the certificate with his proper key, after validation of information present on the CSR. It will not add any further information about the company, only validate and sign. The validation process of the company by the authority will be different for OV or EV, but information present on the certificate stays those provided by the company on the CSR.
The detailed address of the company will appear only if it was provided when signing keys were generated.
This is not typical information required on a certificate, but the company can choose to add personalized information on the Subject field.
I am not aware of any certificate authority who require the detailed address on CSR.
I don't believe so as it would not be very secure to display the company's detailed information. This could lead to someone breaking in or harassing workers where Microsoft could be blamed as they let the company's address go public.
Data about an exe file made with visual studio is created like this inside the AssemblyInfo.cs (in C# projects) in the properties. This is all the data that can be found if I'm correct. Every application made in visual studio will have something like this, I'm not sure about C++ projects, but it should be something around the lines like this.
Lets say you have a windows executable (driver or usermode app), and you want to :
Verify if the digital signature is OK and file is not corrupted (same as when you go to the digital signature tab and it says the certificate is OK)
Find which company signed the file. Therefore I am not talking about the root of the certificate chain (Which is the CA most of the times), I am talking about the bottom certificate in the chain, which is the company that signed the file, i want to get the name of that company.
I found two APIs, WinVerifyTrust And CertGetCertificateChain, But I'm not sure how to use them for this task, or if they can help me with this or not.
Lets say you already have the handle to the file that you want to check, and have read it in a buffer as well, how do you use these to check the certificate afterwards? The documentations are very vague.
Verify if the digital signature is OK and file is not corrupted
For more details about how to Verifying the Signature of a PE File, I suggest you could refer to the example: https://learn.microsoft.com/en-us/windows/win32/seccrypto/example-c-program--verifying-the-signature-of-a-pe-file
Find which company signed the file.
I suggest you could try to use CryptQueryObject function (wincrypt.h).
For more details I suggest you could refer to the Doc:https://learn.microsoft.com/en-us/troubleshoot/windows/win32/get-information-authenticode-signed-executables
And you could refer to the Thread:Read and validate certificate from executable
I have 2 code signing certificates, for both CSR is created same way, also import and export is done same way. The only difference that I see is that one of certificates Common name contains Quotes, and the other doesn't.
e.g.
some cert and
some "cert"
CSR creation
Request format PKCS #10
disabled "Strong private key encryption"
Entered Common name, Organization, Locality, State, Country
2048 bytes for private key
set private key exportable
Import
place all certificates in Personal store
Export
Include all certificates if possible
Enable certificate privacy
encryption algorithm TripleDES-SHA1
Misleading thing is that this Common name value is NOT taken from the value I entered when I created CSR request
I am using those certificates to sign Winforms applications in Visual Studio. Certificate without Quotes in common name is working correctly (i.e. when I install application user is not getting security warning about unknown publisher), but when I install application which is signed with the other Code signing certificate (with Quotes in Common name) - it does not recognize Publisher. No error when published my application. When I take a look at setup.exe properties in Windows Explorer I see a Digital signatures tab which contains row for my certificate.
I tried to sign files with signtool and then verify - it said that certificate is valid.
I tried to get help from godaddy.com where I bought my certificate, they said that it should work with quotes, too, but didn't offer help to solve the issue. Rekey also didn't help.
I see that there are some suggestions to use Pre Publish, Post Build tasks, but I am not using those for my first certificate which is working.
So, is anyone here using code signing certificate for Winforms application with common name having quotes in it? Or maybe anyone knows about this problem and how to solve it?
Had to revoke (common name which is entered when creating CSR is not taken into account, so rekeying is not enough!) my code signing certificate and create from start without quotes/brackets in company name.
So this means, you will have to wait again for few days, because verification process is made from start again. When you will be contacted by issuer, they will verify / ask you about company name - make sure that they do not include quotes/brackets.
Revoking means that you will basically have to buy your certificate once more, because after you revoke it (at least in godaddy case) in your account you don't have options to create it again. So, you have to contact support (use call center and not chat ;)
I'm working on a .NET PDF signature application that allows signing with a SmartCard (Belgian ID). In addition, I'd like the signature to support LTV.
I've followed the instructions and examples from iText, and it seems to work well. Acrobat Reader DC indicates that the signature is valid, and offers LTV.
There is an practical issue however: the included CRL is too big. 14MB on my test ID. This means that, for every signature, 14MB needs to be downloaded which slows down operation and significantly increases the file size of each signed PDF.
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality, however simply removing the CRL and including a OcspClientBouncyCastle instance didn't do the trick. Is the OCSP that is given to SignDetached used to check whether the certificate is revoked at time of signing instead?
A related question concerns the LTV "support" itself. As I mentioned, Acrobat Reader only indicates that the file supports LTV when the CRL is included. Checking at the online service http://dss.nowina.lu/validation (EU reference) seems to indicate something else however. There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data"). As such, I was wondering if it is even needed to include the CRL for LTV?
Suffice to say I'm confused :).
Btw, 2 more warnings from that same verification service that I can't seem to solve: "The 'issuer-serial' attribute is absent or does not match!" and "The signer's certificate is not supported by SSCD!". But maybe thats for another question.
Thanks in advance for any help.
I had a look at your sample document. It does not conform to any LTV profile, merely to T-Level, i.e. it is timestamped.
In detail
The PDF signature is implemented merely by embedding a single CMS container using subfilter ETSI.CAdES.detached which contains
the certificate chain of the signer certificate in the CMS container certificate set
C=BE,CN=Belgium Root CA2
C=BE,CN=Citizen CA,SERIALNUMBER=201103
C=BE,CN=Donny Tytgat (Signature),SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);
a signed Adobe RevocationInfoArchival attribute containing a single good OCSP response for the signer certificate; the response is signed by
CN=Belgium OCSP Responder,C=BE
which has the id-pkix-ocsp-nocheck extension;
a signature time stamp signed by
C=BE,SERIALNUMBER=2014,O=Belgium Federal Government,CN=Time Stamping Authority
Thus, the signature conforms to Baseline T-Level as
A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service
Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually
existed at a certain date and time.
(section 7 - Requirements for T-Level Conformance - ETSI TS 103 172 V2.2.2)
where B-Level conformance is defined as
This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil.
The current clause specifies compliance requirements for short-term electronic signatures.
This clause actually profiles
PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures
that do incorporate signature-policy-identifier) signatures.
(section 6 - Requirements for B-Level Conformance - ibidem)
(Additional requirements also are fulfilled.)
It does not conform to LT-Level which requires:
The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the
validation of the signer, and CA certificates used in signature. This set includes all certificate status
information required for validating the signing certificate, for validating any attribute certificate present in the
signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already
incorporated to the signature.
(section 8 - Requirements for LT-Level Conformance - ibidem)
as there is no revocation information concerning the CA certificate or the TSA certificate.
Thus, it can also not conform to LTA-Level as
A PAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more
document-time-stamp has been incorporated
Concerning other questions
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality
Given an appropriate PKI infrastructure that is possible. Unfortunately, though, neither the CA not the TSA certificate contain information on a OCSP responder responsible for them. Thus, either the Belgium citizen PKI does not provide OCSP services for those certificates or it merely does not make that provision public.
BTW, this is what the Diagnostic Tree remarks
<Message Id="0">OSCP Uri not found in certificate meta-data !</Message>
are about which you get when verifying your signature using the http://dss.nowina.lu/validation service.
There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data").
This user interface layout has misled you, as mentioned above there are more requirements for LTV-related profiles.
I have another question to security in the web.
If I understand it correctly certificates are for identify who you really are. So the man in the middle attack isn't possible.
But when I see this image:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/800px-Digital_Signature_diagram.svg.png
I think a man in the middle attack is possible. You could split the Signature, the certificate from the data. Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
What I also not understand in this picture is where the certificate gets checked, on the verification side.
thanks.
SCBoy
Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
The problem is that the receiver will then look at the fake signature and see that it does not match the certificate of the real sender.
You can only create signatures that match a given certificate when you have the correct private key for that certificate (even though the certificate itself is public, that is the magic of asymmetric cryptography). This private key is being kept secret by the owner of the certificate (the original sender of the message).
The man-in-the-middle is prevented by distributing trusted certificates in advance.
You have to trust the authenticity of the certificates, either by trusting them directly (root certificates) or by trusting a chain of signatures on the certificate leading up to one that you trust.
If the man in the middle can make you believe that his fake certificate is the real deal, then the whole system fails.