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
Related
I looked recently into signing my application. The price is AT LEAST one hundred euros/dollars per year for EV (anything less than EV seems pointless anyway).
My application uses a basic installer (self-extracting WinRar) that requires no admin password. But the drawback of this is that I cannot install the app in Program Files.
The actual problem here is that you will find lots of resources that tell you how to sign your app but not so many (at all) that tell you if there is any real advantage. For example: do the regular PC users care when they install and app and Windows shows "Publisher: unknown" or they just quickly hit the OK button to have the installation process done as soon as possible?
Honestly, I don't think that the user reads and cares about "unknown". That might stop him is actually the yellow color (instead of blue).
So, my question for those that already did code signing for their apps is: have you seen an improvement (downloads, installations, sales) after signing your app?
Should I invest any time/money/energy in this?
Update: It seems that having the app signed is not enough. After that, you have to keep fighting to improve your reputation factor, otherwise, Microsoft SmartScreen might pop-up: https://mkaz.blog/code/code-signing-a-windows-application/
For those interested in prices, here a few random offers sorted by price. I will also post the documents required:
Signing a Windows EXE file
For those interested in prices (and few extra tips), here a few random offers sorted by price.
The documents required (by Sectigo, in my case) for obtaining an OVL are:
company's registration certificate
a photo of you holding your ID close to your face
a phone landline so they can call you for verification (it as actually a robot calling you to give you a number, that you have to enter then into the browser).
The whole verification process (especially phone) took like 2 months because they involved some kind of automatic calling that did not work on my line/phone?.
I will post soon the number of downloads necessary to get reputation for your newly signed exe file. At this point, I can tell you that 1000 downloads are not enough.
I am trying to prototype a X509 certificates based group enrollment, and not for only one device (as dice_device_enrollment by default would provide), but for several, and, from what I learned, I will need to implement my own custom HSM library. While most of the latter seems straightforward, I have a difficulty with setting deviceID. The document says the following:
custom_hsm_get_common_name
char* custom_hsm_get_common_name(HSM_CLIENT_HANDLE handle);
Retrieves the common name from the x509 certificate.
Passed to the Device Provisioning Service as a registration Id.
My difficulty is - if "registration ID" is deviceID, and an X509 certificate has only one common name, how am I supposed to provision multiple devices in a group? Or, is there any other way that deviceID is set? Currently by analysing the code of hsm_client_riot.c I can't see that.
Just to close this one. Since July 2019 a new version of Azure IoT SDK for Python has been released, which handles device provision better than the old SDK (which I was referring to). The question is obsolete now. Use the new SDK.
I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:
Get the Cert via email or AppConfig
Store the Cert (securely)
Extract Identity and Trust from the Cert.
Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.
Turn Identity and Trust into the auth response challenge.
My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().
But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.
The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?
The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly
I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:
The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.
Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.
Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy
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.
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.