VS2022
I have succesfully built and archived my Xamarin.Forms app. I've used ad hoc distribution many times in this project, successfully.
With my last archive, it failed to sign the package, quoting the error Signing Packages Failed. 'Keystore was tampered with, or password was incorrect.'
I used this process after successfully archiving:
I click Distribute => Ad Hoc.
I select my signing Identity, and select a save location.
I am prompted for my password, which contains only 6 lower case letters.
I get an error:
Signing Packages Failed.
Keystore was tampered with, or password was incorrect.
Following other SO threads I have:
I've rebooted.
I've rebuilt and re-archived.
I have since deleted the keystore.
I've reinstalled xamarin forms after deleting the 'mono for android' folder.
Still, even with a brand new key (taking care for no special characters), the package signing fails.
I'm absolutely tearing my hair out - can anyone advise how to fix this ridiculous problem?
Related
I am currently developing a WinUI 3 application, but I believe the details of the application type are not that important for the question I have.
The application comes with a "Package project" for publishing the application using MSIX:
In the editor for the "Package.appxmanifest" file in the package project there is a "Packaging" tab that has a "Choose certificate" button for selecting a ".pfx" certificate file.
How I obtained the ".pfx" file:
My IT department logged onto my machine while the application for the windows certificate store was open. There we added a new "Code signing" certicate under "Own certicates", but which is not issued by me, but by the IT department. They told me that this certicate should also be trusted by client machines, when I publish applications signed with it, because it was issued by them and so it has a valid trust chain. Later I exported a pfx file based on that certicate which I am trying to use now.
Now, upon selecting this .pfx file in Visual Studio on the 'Packaging' tab, I get this error message:
Unfortunately the "The manifest designer could not import the certificate" error message does not come with the exact reason what the problem is.
I am quite sure that my certificate has a valid date and also is made for "Code signing".
I already found out that there are other users wondering about how to fix the certificate if this message appears. But nobody seems to know how to get told about the exact problem.
Is there some way I can use Visual Studio or Powershell or some other tool to tell me what the exact problem is for the certificate when I select it in Visual Studio and this error appears? I would like to have more detailed information than "there is something wrong with the exported .pfx certificate" that I can give to my IT department.
I am aware that I can specify this setting in the project file of the packing project in order to stop the error from appearing:
<EnableSigningChecks>false</EnableSigningChecks>
But I would also be very interested to know what the exact problem is. Thank you.
Additional information:
To check the pfx certicate file, I also executed the "certutil" command (with the -v option) as indicated here: https://superuser.com/a/580698/543294 In the large text dump file I find an issuer that I also find in the list of Trusted Root Certification Authorities of the certicate management application.
Did you edit the Publisher attribute of the element in your Package.appxmanifest to match the Subject property of the certificate?
This should not generate the error above. In the worst case, it could let you build the package and then fail to install it due to this mismatch, or it could fail to build the package.
What I suspect is that IT gave you a code signing certificate that they generated (instead of buying it from a certified vendor). This is perfectly fine if you plan to deploy your application only internally, inside your company, as they can deploy that certificate to all other machines from the company, so those machines trust it.
However, if the certificate was indeed generated by IT, and they didn't deployed yet to your machine, VS might see this is not a trusted certificate and could give this error.
You can check if the certificate is trusted by opening certmgr console and searching for the certificate in the Trusted Root Certification Authorities hive.
If it is not there, double click the PFX file and follow the wizard (from steps #4) to install it.
I had successfully uploaded an app for TestFlight but after archiving and uploading now it is giving me this error I can't explain. Just to make sure I unchecked all entitlements in the capabilities target tab but that doesn't seem to matter.
I looked over all the app id's, certificates and provisioning profiles but there's nothing that looks abnormal. I would look in the actual .plist file generated by Xcode but I don't see where it is or if it even exists. Where should I even check to verify what's going on? Xcode is a buggy mess so I don't even trust this isn't some random bug (I cleaned the target of course just to make sure).
Automatic signing is unable to resolve an issue with the "..."
target's entitlements. Switch to manual signing and resolve the issue
by downloading a matching provisioning profile from the developer
website. Alternatively, to continue using automatic signing, remove
these entitlements from your entitlements file and their associated
functionality from your code. Then rebuild your archive and try again.
Provisioning profile failed qualification Profile doesn't match the
entitlements file's value for the application-identifier entitlement.
I had a terrible time with some old projects where I had to use manual signing because I couldn't get automatic provisioning to work. Then I discovered the following solution, which has worked for me 100%:
Switch to automatic provisioning if you haven't already.
Edit the target build settings and search for Sign. You should see four Code Signing Identity entries and they should all say iOS Developer. (If one of them says iOS Distribution, that's the kiss of death.)
Still editing the target build settings, search for Provision. Scroll down to the bottom and see if there is an explicit extra provisioning profile setting giving a profile number. If so, delete it.
Edit the target capabilities. Turn Game Center and iCloud and In-App Purchase on. Now turn them off again. This will give you an empty entitlements file (you can confirm this in the project navigator).
You will now be able to build to a device, archive, and export to the App Store, using automatic signing throughout.
I have had a very similar issue with Xcode 9.4, the only difference being that the error referred to issues with both the application identifier and keychain access groups entitlements.
I switched from automatic Xcode signing to manual signing to try to fix the problem. After some mucking about that did not help (and that I don't think contributed to fixing the problem) I ended up re-enabling the Xcode automatic signing. This appears to have fixed the problem. I was able to clean, archive and upload without any issues.
Not a particularly satisfying answer, but it worked for me.
I am trying to publish my app on the app store but I get this error. I have no idea where it is coming from. My certifications and signing are managed automaticaly by XCode. (Select is empty because I erased it on the screenshot)
Invalid Signature - A sealed resource is missing or invalid. The file
at path [AlphaBane.app/AlphaBane] is not properly signed. Make sure
you have signed your application with a distribution certificate, not
an ad hoc certificate or a development certificate. Verify that the
code signing settings in Xcode are correct at the target level (which
override any values at the project level). Additionally, make sure the
bundle you are uploading was built using a Release target in Xcode,
not a Simulator target. If you are certain your code signing settings
are correct, choose "Clean All" in Xcode, delete the "build" directory
in the Finder, and rebuild your release target. For more information,
please consult
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
I started a brand new project with Cordova, and I am still facing this error. As Always, Apple error are self-explained (irony). What do I have to do to fix this error ?
Thanks
I'm seeing the same thing in a project (on Xcode 9.2) with multiple targets (different version of a single app framework) - all targets pass except one. One of my apps continued to get this error. Perfect situation to look into why this is happening. I first thought it was the signature profile (development vs distribution certificate). Check that first.
But in my case, I had a few files that were not being used by the code that I had excluded from the build. When I added these resources my build passed. Check to see that all needed resources are included in the File Inspector panel. This includes code and media resources.
I am using Sparkle for the first time, and having troubles getting things off the ground. When I check for updates, it correctly detects a newer version, downloads it, unarchives it, and then gives the following error:
Update Error!
An error occurred while extracting the archive. Please try again later.
The output log shows the following detail:
Sparkle: The appcast item for the update has no DSA signature.
The update will be rejected, because both DSA and Apple Code
Signing verification failed.
My archive is named "MyApp.pkg.zip", and contains only "MyApp.pkg". It has an apple ID digital signature. I verified this by downloading the zip manually, extracting it, running the PKG, and clicking the lock icon on the first install page.
The PKG has been created using Packages.
My appcast has the following:
<enclosure url="http://thedomain/MyApp.pkg.zip" sparkle:version="1.0.0.990" length="5752133" type="application/octet-stream" />
My .app also has the same Apple ID signature as the .pkg, though I don't think it matters at this point of the auto-update process.
So my question is: What am I doing wrong? How is Sparkle concluding that the digital signature is not sufficient, when the PKG is clearly digitally signed?
Do you have different certificates for signing the .app and the .pkg? When you go to create the certificate on Apple's Certificates site, you have to choose one or the other type.
You need to have two certificates, one for signing the .app and one for signing the .pkg.
I'm trying to submit an update to my app. I had messed up some files, so had to generate from scratch all of my the certificates, keys, and provisioning files. Would that be a problem for updating? I read someone saying that updates to the app HAVE to be done using the same provisioning file... that can't be true, can it? Otherwise, I'm in major trouble.
Anyhow, my archive builds keep failing validation. I have triple checked that I'm using the Store Distribution certificate for my release. I also ran codesign command and it came through fine. I have also checked the contents of MYAPP.app bundle and the "embedded.mobileprovision" is there. Why does it say "Failed to load"?
Below is the output I get in my log. Any ideas?
(using XCode 4.0.2)
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)
Executable=/Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/MYAPP
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
AssertMacros: signer, file: codesign_wrapper.c, line: 610
AssertMacros: profile, file: codesign_wrapper.c, line: 914
codesign_wrapper-0.7.10: Failed to load provision profile from: /Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/embedded.mobileprovision
- (null)
You should remove your distribution certificate from your system. Revoke that certificate from developer portal, create a new one. delete the old provision profile and create a new provision profile for app store and use that.
I ended up resolving my issue by moving over to a different machine that had a clean install of all the dev tools. My original install got corrupted because I foolishly installed beta version over it and then tried to revert back, at which point codesign didn't want to play along anymore. I know that wasn't the smartest thing.. but sometimes you do things for the first time and learn the hard way :)
Anyhow, the good news is that new keys and certificates don't really mess things up and life can go on but watch where you install beta versions!
In dev center you can read that it is critical to store your private key somewhere save. It also says that this private key cannot be reproduced if lost.
Therefore I think you are in trouble.