Greetings,
I am responsible for a Java Applet that needs to work on a wide range of Macs. This applet needs access to the file system and thus needs to be signed. On a Mac, even if the applet is signed and the certificate is valid, by default the applet will still not work. You need to open the certificate and put under the trust settings 'Always Trust'.
To know what I am talking about, see mac docs,
Figure 3-3
Now, after installing the most recent update of Java on Macs, the trust section no longer appears and people who visit the site for the first time cannot get the applet to work any more. Any help, ideas, suggestion are very welcome.
T.
Maybe the original certificate (or one of the signing CAs in the certificate's path) is no longer valid. Check dates of all of them in the whole cert path, not just that of the cert itself.
This is fortunately no longer a problem on current OS X Lion.
Related
I'm building a macOS command line app that stores tokens in Keychain as kSecClassGenericPassword. I'm using a self-signed certificate to codesign the app for local development. (I am not adding any entitlements.)
The problem is what whenever I re-compile (and re-sign) the binary, I get a prompt for my admin password whenever the binary accesses the keychain item. According to this answer, keychain should detect that both versions of the binary are signed and have the same identifier, and not ask for my password. Is there anything I'm missing or any workaround to avoid having to enter my password so frequently?
I don't know for sure, but I strongly suspect the issue is that your certificate is self-signed. Most security decisions in macOS are based on the team identifier embedded in the signing certificate. This prevents a malicious program from stealing credentials from another application simply by giving itself the same bundle identifier and being signed. For the authorisation check to be skipped, both the bundle identifier and the team identifier must match.
I suspect that even if you did somehow embed a team ID in your certificate, because the certificate is not in turn signed/issued by Apple, the team ID would (rightly) not be considered reliable by the OS, so your binary is treated as effectively unsigned. I suspect the CDHash (cryptographic hash of the binary code) is used for authorisation instead, and your certificate is ignored.
I don't know your reasons for using a self-signed certificate, but as far as I'm aware you can get a very basic Apple Developer certificate from Apple for free, and using this to sign your binary should suffice for solving the issue you are encountering, as the free certificate includes a Team ID.
The only other workaround I can think of is to use a helper process with the sole purpose of storing and retrieving the credentials, and using XPC to communicate with this from your main binary. The helper process would hopefully not need to be updated as frequently as the main program, so you'd rarely see the authorisation prompt. This is of course still rather awkward, and now you need to secure the XPC service against malicious clients yourself.
I need to upload an app on the account of a client. I logged in with xcode but I can't select the IOS distribution code signing profile, I tried to download the IOS distribution certificate from their member center
But even if I download it and double click in order to install it on the keychain I cannot use it.. Should I create a new IOS distribution certificate or is there a workaround?
I'm not 100% sure. I think you need to have their developer profile installed on your computer. It will want you to export the profile from the keychain on their Mac and you would install on yours. If they only have an account but do not use it for anything other than to sell their app you might be in a better position to just set it up on yours. If they do have it installed then it can be a bit tricky. I don't expect this to be an answer but I hope it helps you find the solution.
Good luck!
You cannot use it, because private key should exist at your machine for this certificate, you cannot download it from anywhere except the export process from machine for which it was generated. In your case request new certificate for your machine.
If I open the app Keychain Access from the Utilities directory I can filter out a list of certificated that the OS uses.
Filtering to show all certificates then sorting by date and I can see that a good portion of the certificates have expired.
Do we just wait for an update or OS update to solve this or are we supposed to manually intervene?
What is the correct procedure? If they are expired, they will kick an error for the certificate if I access it. That hasn't happened to me yet so far, making me think these are rather esoteric certificates and I need not worry too much.
However, it concerns security, and I would rather have them not be there and get an error than get another error where I have to read through the certificate to see why it is not working.
What is the suggested methodology for dealing with the expired certificates in keychain manager in Mac OS x?
I've done codesigning and submitting for iOS apps countless times. This time it struck me with the Mac App Store. I'm repeatedly getting the same error message:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I've recognized this 2 topics here on stack overflow:
mas-code-signing-identity-private-key and mac-app-package-identity-not-installed
Nothing inside there solved the problem for me.
Thats how I (most reliably) reproduce this message:
I clean up all my certificates and private keys starting with "Mac Developer" or "3rd Party Mac Developer". Of course also the expired ones.
Revoking all the stuff inside the Mac certification portal.
Create App-ID (did it only once)
Create new certificate for Mac Development. I can only assume that this is comparable to the debugging certificates for iOS development.
Create new certificate for Mac App. Once again I can only assume that this could be something similar to a distribution certificate in iOS-development.
For completion reasons create a new certificate/profile for my system.
Create a production provisioning profile. I can only assume that this might be equivalent to an iOS distribution profile.
I then download all the certificate mess and install it properly. Some go into the Keychain, others got into the Preferences and XCode.
For making sure I restart XCode or even the whole Mac (doesn't change the frustrating outcome anyway).
I go to the project build settings and select the production provisioning profile, because I assume "production" is equivalent to "distribution". Changing the codesigning identity in the target build settings doesn't work either. While Apple claims in it's documentation that for App Store submission the signing identity has to be changed in the project build settings.
I run an archive build.
I select the archive in the organizer and click validate.
This error message appears:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I can't find any pointer to what the term "package identity" actually means. What is most frustrating to me is that this terminology mess in Apples documentation concerning the code signing and submission process appears not very clear and precise to me. At least not as clear and precise as the documentation for the same process concerning iOS App submission (which is using completely different terminology).
Probably I understood something wrong? Thanx for any help or pointer in advance.
OK, I have some important pointers (additional to Apples documentation) for people stumbling over similar issues.
The error message is totally misleading.
Don't take every word in Apples documentation too seriously.
For solving the issue, 2 points have been most significant:
Additional to all the other profile-mess you need 2 certificates for submission to the Mac App Store (contrary to the same process for iOS App Store submission). Both have to be installed together with their corresponding public and private key pairs.
Mac App
Mac Installer
The codesigning needs to be set on the build target, not the project. I don't remember where but this was described wrong side around in one of Apples documentations.
Eventually my submission worked by keeping to those 2 points.
There is an additional issue with Keychain & XCode.
When Xcode uses a certificate, they want one and only one certificate in your keychain. If you have an expired one, as well as a valid one, Xcode often fails the operation.
So you look at your keychain using Keychain Access, and do not see an expired certificate. It is still there! The default setting for Keychain Access hides expired certificates. Goto the View menu and select Show Expired Certificates. Delete all the expired ones, they are not good for anything.
Quit Keychain Acces and Relaunch Xcode. Xcode often requires a relaunch when adding/deleting certificates.
At that point, the Archive Validate process worked for me.
This is what it was for me as well.
Just want to clarify, you absolutely need both Mac App Distribution and Mac Installer Distribution certificates. Thanks Jacque for your explanation above. It should look like this:
Yes the problem is Mac Installer Distribution certificate.
The easiest way to have everything fixed and loose all the troubles just go to Xcode->Window->Organizer->Devices and then on the lower right corner press on Refresh and log in with your account... xcode will generate and download all the certificates and provisioning profiles needed.
I have recently created a small VB application for a friend of mine, I am using the publish feature included within Visual studio (it's the easiest way of updating it and having the updated version downloaded automatically) but when I download it, it downloads "setup.exe"
Chrome and AV's seem to think this is a virus, why is this? I have made it a full trust application and signed it with a certificate and a key, but it still think's it's a virus, any ideas?
Answer 1 Copied and pasted from http://productforums.google.com/forum/#!topic/chrome/r-9JQIboUmc
I was able to get around it without a code signing certificate, just by using SSL (which uses a less expensive certificate, and I already had one to secure access to my website), but as your experience shows it seems SSL isn't the only way...
Based on my experience and what I've read of others here, my theory of how Chrome validates downloads is that it goes through a checklist like this:
Is the host site known and trusted? (i.e. large established sites are OK)
Can the identity of the host site be verified? (i.e. via SSL certificate)
Can the the identity of the file's publisher be verified? (i.e. via code signing certificate)
Is the file known and trusted? (I had a file up for a while that was unsigned and accessed without SSL - Chrome was fine with it until I changed the binary after the security update... I'm assuming it takes some time to reach this status.)
If one of these criteria passes, the download is not flagged as malware, and if they all fail, it is.
Answer 2: Copied from http://blog.chromium.org/2012/01/all-about-safe-browsing.html
Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.