We have a .net WPF application running as both XBAP and Desktop etc.I haven't signed any assemblies etc.My question is that
Q1.What kind of Digital Certificate do I need to purchase from VeriSign, Inc., or another certificate authority. to sign my application,use it as Authenticode Certificate (in clickonce) ?
Q2.Can I use this Digital Certificate to sign other applications like installers,assemblies,pdf etc?
Q3.Is one Digital Certificate enough for a company or I have to buy other?
Q4.What happens when the Certificate expires? (So is it better to not have it and screw yourself if no one is gonna hack and plant a virus in you app folder or something ???)
A1. You need a code signing certificate. They come in several flavours, and typically can be converted from one to the other, but it's probably easiest to get an Authenticode one rightaway.
A2. You can use the same cert to sign installers and assemblies (and any .EXE, .DLL, .OCX file). I think the same applies to .PDF, but I've never used that.
A3. I'd go for a single cert for your company.
A4. When the cert expires, you cannot use it for signing anymore. However, as long as you use a timestamping service when you sign your code, already signed files remain valid.
A1: You need code signing certificate. You may choose any provider, but do notice that not all of them are recognized by Windows as "trusted". Among trusted and cheaper ones (cheaper then VeriSign) there is Comodo.
A2: Yes.
A3: One is enough.
A4: You will not be able to sign new code. Old code will remain signed if you used timestamp server (you'll get location of one with certificate). If you opt not to use timestamp server, certification will remain valid, but users will get message that it it expired.
Related
I am trying to implement signed code for some PS scripts, and I have a question about trusting certificates.
I know the "right" way to address this is for IT to use Group Policy to trust the certificate office wide. But many of my customers just don't really have that option. My thought is to provide instructions on using CertUtil.exe to do the job, but I wanted to be 100% sure that adding to trustedpublisher this way still results in the certificate being validated by the issuing authority at startup or login, so a revoked certificate in trusted publishers would in fact not be trusted, correct?
Also, give that the tool to be run is a management tool, my initial thought is to use the tool to drive CertUtil.exe. Basically the first time you use it it adds its own certificate, so you get some user interaction required on first use only. But the idea of code creating a trust for itself seems potentially sketchy, and would raise a little flag for me if I was on the other side wearing my IT hat. So, from a PS distribution model standpoint, is setting up one's own certificate considered appropriate, or verboten, or something of a gray area?
If I recall correctly revocation is almost immediate, with a possible short time lag due to pre-fetching. you can find more info on how exactly revocation is handled here - https://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx
As far as adding your own cert I don't see an issue with it but if they require code signing for scripts it won't be able to do it's initial launch, personally I'd send the certutil stuff as a separate script (potentially a batch file) and keep the code you are actually sending over all signed.
I have associate my Windows Store app with the Windows store and I got a "Appname_StoreKey.pfx" key file, and I deleted my temporary key. If I create my app package using this key will my app expires after a month?
Temporary key expires on a month but this StoreKey says it will expire after a year. Please explain any cons of this procedure.
Due to company requirement I can't submit the app to the store.
The test certificates will expire one year (not month) after creating them. Technically you can use these to publish your app, but this is not recommended.
The same is true if you get a [appname]_StoreKey.pfx after associating your app with the store.
You can view the expiration date in VS, see screenshot.
This cert is taken to sign your code. The app package signature ensures that the package and contents haven't been modified after they were signed.
When you're not deploying using the store the disadvantage is that during deplyoment, the certificate is not trusted. This is in both cases no matter if you take the testcert or the storekey.pfx.
Your users are required to first install the certificate. This is something they might not be able to do (missing rights) or don't dare to do (because they're scared).
When you take a closer look, you will find that the issuer name of testcert might look good, and probably looks very strange (long guid) for a StoreKey.pfx . So users who are asked to install the cert might be scared for a reason.
The best way is to use your own certificate that you created that won't expire too early and that is installed by your IT device management Infrastructure (if you're building a company app for example). This will lead to a struggle-free installation for users.
Using a test certificate is possible technically but not a very "clean solution".
Also check out this post
https://msdn.microsoft.com/en-us/library/windows/apps/br230260(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/apps/jj835832.aspx
My company develops an ERP for hospitals and because of some legislation changes throughout this weekend I've been reading a lot on digital signature because I need to solve the following scenario:
Each doctor will receive from the ministry of health a certificate (so there's no escape from it... government said so...) and all of his reports sent/stored in digital format must be signed with this certificate.
The certificates will be valid for one year. Each year upon renewing of the medical license, the certificate will be renewed.
Our main concern here is guaranteeing the source of the document (the sender is who he claims to be) but we must also make "impossible" (or at least infeasible) to change the content of the document (or at least that if it changes, we have to be able to tell that a modification occurred) and to "extracted and replicated" the signature...
My question is: how do I deal with this whole thing? What should I do?
PS: In your answer pls consider that:
The documents will persist far beyond the certificate lifetime.
The certificate might have been revoked. Documents signed before the revoke must still be valid
How a 3rd party would verify the integrity of the information (document + certification)
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
I'm really new to this area and I might be asking the wrong question...
In brief, the document must be signed using CAdES, PAdES or XAdES (depending on data format) standard, where timestamping is applied and other measures are taken. These standards were designed specifically for tasks similar to yours so they address your concerns. I recommend that you read some articles about those formats. Unfortunately I don't have a link to share with you right now, but you can find a lot based on those abbreviations.
CAdES is based on PKCS#7/CMS (certificate-based signing of generic data with wrapping signatures) .
PAdES is an extension of PDF signing and is used specifically for PDF documents.
XAdES is similar to CAdES and can be used to sign XML documents and (more rarely) binary data.
[Disclosure: I work for CoSign by ARX.]
Your situation is common. You're raising a number of questions. My answers:
all of his reports sent/stored in digital format must be signed with this certificate.
You can digitally sign anything (any bundle of bits). The real issue is how can the recipient or auditor easily verify that the document:
was not modified since it was signed (integrity)
was signed by the right person (identity)
was signed with the right intent (signer's statement)
Machine readable data, eg form data, intermediate data, etc.
Signing: For info that is designed to be later machine-read (eg a form submission), store the info in XML and sign it using the XML Signing Standard: XAdES The CoSign Signature API (SAPI) directly supports signing XML docs.
Verifying There are many on-line XML digital signature verification services, Google for them. The SAPI api also supports verifying XML docs.
Human readable documents
Signing: For a "final" document that will be read by humans (but is stored digitally, can be included in searches, etc), PDF documents are the way to go. The PDF format supports digital signatures very well. There are many ways to add digital signatures to PDF documents. For developers, the CoSign Signature Web Agent is a web service (HTTPS + XML parameter document) that handles all the UI issues of signing.
Verifying: The most common way to verify the digital signatures of a pdf is to use the free Adobe Reader. (Not the expensive Adobe Acrobat.) Adobe Reader knows how to check the validity of the digital signatures and then tells the reader/signer/auditor that the signature is valid, the document was not changed since signed, etc.
Your other questions:
The documents will persist far beyond the certificate lifetime.
Yes, that is fine. Just like a "wet signature," once you've validly digitally signed a document, that document remains signed by you. -- Even if your signing certificate later expires. As part of the verification process, the date of signing is compared with the valid dates on the certificate.
The certificate might have been revoked. Documents signed before the revoke must still be valid
Yes, that is how standard digital signatures work. Even if a certificate is revoked, documents signed while the certificate was valid will remain signed. Because date/timestamps play such an important part of the validation process, there are 3rd party timestamping services available. But they are not used for most digital signatures. Instead, create explicit management procedures to make sure that the time server is properly setup with NTP to a good source and that the system is regularly checked and verified.
CoSign signs using a tamper-proof hw device. Its clock is synched using NTP.
How a 3rd party would verify the integrity of the information (document + certification)
As I discuss above, the whole verification question is important. That's why I recommend using XML or PDF as your document types. You could, for example, digitally sign your own system's internal data structure used to represent information. In this case the digital signature would be carried in a separate data structure. This is the "external signature" scenario. It all works fine, except that an auditor would need to either build his own sw to validate or trust that your sw is doing the validation properly. A better choice is to use a format that directly supports digital signatures and which can be easily verified.
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
A proper digital signature system won't allow an expired certificate to be used to sign anything. Once something is signed, using a certificate that was valid at time of signing, it stays signed unless the document is subsequently changed.
I'm really new to this area and I might be asking the wrong question...
Other questions to ask: how do you add the signer's graphical signature to the document (XML or PDF)--people expect to see it. And how do you manage/administer the certificates? Server based signing is a good solution for this. Remember that certificates should not be stored in sw for any production systems. Instead, a Secure Signature Creation Device (something hw based) must be used.
You will also need to read the Baseline Profiles where there is a profile for long-term signatures.
There is a profile for each of the formats already mentioned by Eugene.
For example, if your document is PDF, you may use PAdES signatures and the LTA-Level specified in "PAdES Baseline Profile" document.
All of these documents are ETSI standards you can search for at: http://pda.etsi.org/pda/queryform.asp
I am curently working with a system, that has PDF signing option.
Now, when creating a complementary Android application, I've run into a bit of a conundrum: How do I check the validity of the certificate?
The problem is, that I'm interested whether the certificate was valid at the time of signing. Now I know, that Adobe has this kind of capability, but I'd like to know how to implement such a thing on my own.
I've succesfuly checked the status of the certificate against OCSP, but the only thing it gives me status of the certificate, whether or not it has been revoked/suspended and the date (which is incorect, and still puzzles me). I've also taken a look at CRL, but it seems, that it only has one record per certificate, meaning, it can't tell me whether or not a certificate was valid at a specific point of time.
Example:
Certificate 01 4D 44 5B - issued on 20.08.2012 - suspended on 21.08.2012 - reactivated on 22.08.2012
PDF document1 - signed on 20.08.2012
PDF document2 - signed on 21.08.2012
Now if we check the documents validity in Adobe Reader, PDF1 would show valid and PDF2 as invalid.
How does Adobe knows, and how do I find out the same information? Maybe there is some OS programm, who's source I could take a look into, to find this out?
This usually done by embedding a timestamp in the digital signature, usually itself signed by a different but trusted CA, like that used in Microsoft authenticode. This timestamp is compared to the validity period for the certificate to determine whether the certificate was valid at the time of signing.
Also see How does countersign in code signing work? or the signtool.exe /t option for more discussion on this.
On iOS, I know that we can evaluate a trust with SecTrustEvaluate(). To create a trust, we either import it from a *.p12 file or create it using an array of certificates and a set of policies.
I also know that in order to ensure that a server, that is not trusted by default, is trusted, we can use SecTrustSetAnchorCertificates() to augment the list of root CAs SecTrustEvaluate() uses to verify the server's certificate.
Now, how can I ensure that these anchor certificates are available on a subsequent launch? I can store certificates, keys and identities in the application keychain, but not a certificate chain. Even if I store all the certificates in the chain, how will I know what certificates are to be used as anchor certificates?
One solution that comes to mind is to just get all the certificates from the keychain and set them as anchor certificates. Another method could be to all the certificate chains on the disk as *.p12 files and load them once on every application run.
eskimo1 from Apple Devforums answered this so:
First up, you don't need to store the certificates in the keychain. You can store them elsewhere if you like (and create the SecCertificateRef using SecCertificateCreateWithData).
Secondly, your question talks about .p12 files, but I'm not sure what this has to do with things. In general you only use a .p12 file to distribute confidential information, and certificates are not confidential.
Finally, you can store a certificate chain by just storing the persistent reference to each certificate in that chain (or by storing the actual data of each certificate).