We have now purchased two Code Signing certificates that are supposed to work with Authenticode for downloads. We used Comodo for our source and I am certain we have the correct type of certificate.
We set up Installshield to sign the setup package and followed all the directions I know of. After more than a full year we still get treated as if our code is unknown and our users have to override the security objections and install.
What do we have to do to finally get this thing working? I have searched the net and we are doing everything I can find yet it is as if our code is unsigned.
How do we get a reputation? How many downloads are needed? Our app is downloaded hundreds but not thousands of times per year approximately, does that matter?
Please advise, we are incredibly frustrated as are our users.
Related
All of a sudden Google started to say my application is a virus. Does anyone know the best way to reach out to them and to have a "closer" look? Microsoft has a SmartScreen submission page where you can upload your application and ask them to review it, and it works great & fast...
Every single antivrus other than Google's Cyren says my application is safe, including: AVG, ESET-NOD32, Mailware Bytes, McAfee, Symantec, Webroot, BitDefender, and etc... (I just listed the "famous" ones)
Cyren currently does have a way to submit such samples. They accept submissions via E-mail (with zipped and password-protected attachment), and via FTP.
For details, please see: https://www.cyren.com/support/reporting-av-misclassifications
Please note that Cyren is not owned by Google, and VirusTotal is in fact listing it as a separate positive result. I was unable to find what Google product is used. My best guess would be Google's SafeBrowsing.
I have a specific need inside my organization and want to know if it would be possible. Any suggestion would be appreciated;
Inside my organization, for several reasons, there are distributed a lot of certificates installed inside each worker computers. Each worker may have maybe 5 or 6 certificates to access several webs, sign documents, etc. Each time a computer is broken and reinstalled, or a new worker is hired or someone is fired, the management of that certificates, become a real headache; removal, re-installation, etc.
I am proposing to my organization to develop some kind of certificate repository to centralize the several certificates of my organization.
My questions are about to the possibility to develop and change or implement the keystore o a new CSP or KSP so this new crypto provider could access a central service/server/repository to present (authenticate), and sign documents every time a specific user needs it.
In the case of computer reinstallation, just installing the developed driver/csp, would give access to the central certificate repository.
The concrete questions are if you think it would be possible to develop that driver/CSP/KSP piece of software and what is your opinion about the possibilities to implement it successfully in a maintainable way into MS-Windows environments. How would you focus this development?, just some tips about what it would be possible or not.
Regards,
Definitely it can be done because there are solutions like RedTrust from Evolium that do exactly this.
A centralized certificate store that also allows to manage the usage of the certificates.
I have created one static library in iPhone sdk, and I am worried that If I provide code to anyone in which static library is being used, then anyone can use static library. So Is there any way to restrict them by using library until they get license? I am new to licensing any library.
This is a problem you must solve by legal means, not by any technical solution.
Make sure to only give the library to people you trust, and if needed have them sign an agreement not to spread it.
Also ask yourself if it is worth the trouble. Is your code so unique that they can not find it elsewhere, or duplicate it themselves in a few days, using Google and stackoverflow alone?
As said by #PeyloW,
This is a problem you must solve by legal
means, not by any technical solution.
But there are some simple ways to "block the code": You can create a RAR or ZIP archive, encrypted with password, and after they get license, you can tell them the password.
If you want to "Bind" license to a "developer's computer", than you simply need something that you can bind. For example that can be the emulator's UDID.
you can generate a license for emulator's UDID, and only limit emulator development, while allowing unrestricted access for ARM code (on device)
so you can basically check for emulator UDID
check license file
if license file allows that UDID, run
if not then show a message etc
for development purposes, everybody needs emulator, so I guess limiting it is enough for you.
Personally, I would create a new static library, check your code coverage and copy in only the code used by the app consuming it. Or in other words, don't give away more than you need to.
Then, as someone mentioned in the comments, obfuscate the calls. Your library is going to be worthless without documentation if your calls have to be deciphered. Odds are that anyone that has the aptitude of deciphering what your calls mean probably has 80% of a white-room reverse-engineering of your code already done.
You can't really force a license upon your client at the final hour unless they agree to it. So even if you did try to force them to license your library, it might not even be valid to do so with the original agreement intact. I'd do damage control to the extent your time is worth and chalk this up as a learning experience. 5 months from now, you'll probably have that static library re-factored to something better anyway. And next time, you'll work that into your agreement.
If you provide the static library, no one can get back the code.
Do you have reservations in others using your static library also?
We have a code-signing certificate, purchased from GlobalSign for Authenticode signing (as they call it). Now we need to sign Java applet and soon Adobe AIR module (applet?). The question is: from technical point of view is there any difference between certificate-for-Authenticode and certificate-for-Java or certificate-for-AIR, if they are issued by the same CA (say Comodo or GlobalSign)? I don't see a point in buying different certificates if they are replaceable.
I understand that key usage field of certificates must be the same (code signing), but maybe extended code usage or policy or other extension differs in those certificates. I would appreciate if somebody who has code-signing certificates of two or more types issued by one CA could check this for me.
There's an explicit statement at http://www.adobe.com/devnet/air/articles/signing_air_applications.html that:
"A developer can use any class-3,
high-assurance certificate provided by
any CA to sign an Adobe AIR
application."
Unfortunately, I can't find anything similar for Java. However, regardless of the minimum certificate requirements for the various platforms, your best bet might be to contact your existing certificate provider to ask if there are any meaningful differences between the certificates they offer for these platforms.
Some of the blah-blah on the Verisign website suggests that the format in which the certificate is delivered to the purchaser is the only real difference between their offerings, but they don't actually state this directly, so who knows...?
From what I gather from RFC 5280, the key usage extensions can only decide whether the certificate is usable for code signing or not. There doesn't seem to be anything in the RFC that can constrain whether you sign Java code or AIR or whatever. This seems to imply that if you can sign one piece of code (or any other kind of non-key data) you can sign any.
That said, there may be CA-specific extensions in your certificate. Without seeing the certificate it's hard to tell if there are limitations.
From a technical perspective, as long as the client (i.e. the browser if we're talking about applets) recognises the CA and is happy with your combination of key usage and certificate type (DIGITAL_SIGNATURE and OBJECT_SIGNING) then you should be fine.
It seems that any code signing certificate will work for any mentioned platform. I asked GlobalSign support about the difference - they didn't respond, however soon after that they have changed their web page and now you would be buying one code signing certificate for all platforms.
I am a developer working on several iPhone apps. I am an administrator in our Apple dev portal team. The Agent of our team is NOT a developer. I understand that ONLY the Agent can request an ad hoc deployment cert, and prepare an app for ad hoc distribution.
I assume that the Agent can generate the certificate and pass them to me so that I can provision and build the app for ad hoc distribution, but I have read horror stories about using multiple certificates in xCode. Just getting set up for development testing on the device was complicated enough!
Has anyone dealt with this issue? What pitfalls are there in using multiple certs in xCode? I suppose that I would also need to have the Agents public and private key in my keychain.
It's not a nightmare, it can just get a little confusing, especially if you give your profiles unhelpful names like "distribution profile." If you expect to have multiple sets of profiles, certificates, and keys on your computer, make sure they are named so that you know what goes with what and belongs with what.
I posted some recommendations in this area a while ago.
My number one piece of advice is to give your private keys descriptive names. Fortunately, you can do this at any time in Keychain Access. By default they are simply named "Private Key" and if you lose the certs you'll have to resort to some openssl geekery to figure out which key goes with which.
You are expected to use separate development and distribution certificates; you actually set up different configurations for them. The "nightmare" comes when you use several different development certificates. If anyone touches the certificate setting on the Debug configuration, it must thereafter be set manually (which is a pain in the ass, of course).
So no, there's no problem with the Team Agent giving you his distribution certificate and private key (you'll need both). He needs to realize that Apple will hold him responsible for your distribution of packages, though.
The main issue is that you'll need the Agent to export the private key they used to generate a certificate request for on the portal. The portal has instructions for backing up and transferring that private key... only when you have that key on your system can you make use of the certificates they create for Ad-Hoc.
The docs at this point for the whole process are pretty good, but you must read through them very, very carefully and follow eery step to the letter.