How to fix dylib with invalid signature? - swift

Yesterday I was having an issue to run my app after auto code signing. See the question I post here yesterday.
After spending some time to investigate the issue it turns out the framework certificate somehow corrupted.
The solution is to fix the invalid signature for the framework, and here is how to do so.
P.S. One thing we are certain is that we did tick the Sign On Copy checkbox.

NOTE: VideoBuilderLibrary is a custom framework we built.
To test the code sign state,
# Replace the framework to yours
codesign -v
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib
[no output]
If there is any invalid signature,
codesign -v
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib
frameworks/VideoBuilderLibrary.framework/Frameworks/libavutil.55.dylib:
invalid signature (code or signature have been modified)
In architecture: x86_64
To resigned all dylib files in a framewor and fix this, run command below with "YOUR CERTIFICATE NAME" replaced with your cert file name,
cd frameworks/VideoBuilderLibrary.framework/Frameworks
ls | xargs codesign -f -s "YOUR CERTIFICATE NAME"

Related

Install self-signed certificate to personal store from .cer file using c++

I try to create a certificate for testing purposes in two steps. First, I create a self-signed certificate which establishes my own Certification Authority (CA). Second, I use that root certificate to sign a test server certificate which will be placed in personal certificate store. I open an administrative command prompt and enter the following:
Step 1:
MakeCert -pe -n "CN=TestCA" -b 01/01/2015 -e 01/01/2020 -ss my -sr currentuser -a sha256 -sky signature -len 2048 -r "TestCA.cer"
Step 2:
MakeCert -pe -n "CN=localhost" -b 01/01/2015 -e 01/01/2020 -eku 1.3.6.1.5.5.7.3.1 -in "TestCA" -is my -ir currentuser -ss my -sr currentuser -a sha256 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -len 2048 "Localhost.cer"
Following those steps, everything works fine. After that, I try to install those certificates via c++ application. It seems to be fine when I check those certificates in certmgr.msc, however, client always fail to connect to server since then. After deleting certificate "localhost" from personal certificate store, then do step 2 using MakeCert.exe again. Client can success to connect to server. Maybe there is something important that I was missing. If anyone knows it, please give me some suggestions. By the way, my client and server are running in the same computer. My codes are shown below.
HCERTSTORE hMyCertStore = NULL;
if(hMyCertStore = CertOpenStore(
CERT_STORE_PROV_SYSTEM, // The store provider type
0, // The encoding type is
// not needed
NULL, // Use the default HCRYPTPROV
CERT_SYSTEM_STORE_CURRENT_USER, // Set the store location in a
// registry location
L"MY" // The store name as a Unicode
// string
))
{
printf("The system store was created successfully.\n");
}
else
{
printf("An error occurred during creation "
"of the system store!\n");
exit(1);
}
CRYPTUI_WIZ_IMPORT_SRC_INFO importSrc;
memset(&importSrc, 0, sizeof(CRYPTUI_WIZ_IMPORT_SRC_INFO));
importSrc.dwSize = sizeof(CRYPTUI_WIZ_IMPORT_SRC_INFO);
importSrc.dwSubjectChoice = CRYPTUI_WIZ_IMPORT_SUBJECT_FILE;
importSrc.pwszFileName = L"C:\\Temp\\MakeCert\\localhost.cer";
importSrc.pwszPassword = L"";
importSrc.dwFlags = CRYPT_EXPORTABLE | CRYPT_USER_PROTECTED;
if (CryptUIWizImport(CRYPTUI_WIZ_NO_UI,
NULL,
NULL,
&importSrc,
hMyCertStore) == 0)
{
printf("CryptUIWizImport error %d\n", GetLastError());
}
Any help would be greatly appreciated.
Clement
I've found the difference between MakeCert and my application. After installing by MakeCert, I opened certificate dialog's General tab, then I found there is a string "You have a private key that corresponds to this certificate, but using my application, there is no string in the dialog. I think that I've missed some steps during the install procedure. If anyone know, please give me some suggestion.
Thanks.
Clement

Create your own certificate - "The Manifest Designer could not import the certificate"

I want to create certificate to signing my application:
c:\certcenter> makecert -sv demas.me.pvk -n "cn=demas.me" demas.me.cert -b 01/01/2014 -e 01/01/2015 -r
Succeeded
c:\certcenter> pvk2pfx.exe -pvk demas.me.pvk -spc demas.me.cert -pfx demas.me.pfx
When I am trying to select certificate in VS I get error message: "The Manifest Designer could not import the certificate".
Here is Publisher, Publisher name in the appmanifest and error message:
How can I fix this error ?
Step by step, instructions for one that can be found at https://learn.microsoft.com/en-au/windows/desktop/appxpkg/how-to-create-a-package-signing-certificate
and essentially are:
MakeCert /n publisherName /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e
expirationDate /sv MyKey.pvk MyKey.cer
Pvk2Pfx /pvk MyKey.pvk /pi pvkPassword /spc MyKey.cer /pfx MyKey.pfx [/po pfxPassword]
The options passed in to MakeCert are explained in the page, but here's an excerpt:
/r Creates a self-signed root certificate. This simplifies management for your test certificate.
/h 0 Marks the basic constraint for the certificate as an end-entity. This prevents the certificate from being used as a Certification Authority (CA) that can issue other certificates.
/eku Sets the Enhanced Key Usage (EKU) values for the certificate.
/e Sets the expiration date of the certificate.
(...)
Update:
Please be aware that when using MakeCert with expiration and start dates it uses the format of mm/dd/yyyy so 12/09/2018 is the 9th of December 2018, not the 12th of September 2018.

How to Embed JavaAppLauncher to sandbox for App Store

I'm trying to send a Java application to the MacOS X App Store. All my code is correctly signed (jars, dylib, etc). Unfortunately, when sending the binary, I always get an "Invalid Binary" error with the following message:
Dear developer,
We have discovered one or more issues with your recent delivery for "tamaggo ibi desktop". To process your delivery, the following issues must be corrected:
App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox page for more information on sandboxing your app.
• tamaggo ibi.app/Contents/MacOS/JavaAppLauncher
Once these issues have been corrected, go to the Version Details page and click "Ready to Upload Binary." Continue through the submission process until the app status is "Waiting for Upload." You can then deliver the corrected binary.
Regards,
The App Store team
I Googled this for an entire day but didn't find anything. Does anybody have a clue how to sandbox the JavaAppLauncher in the .entitlements file ?
In order to give more informations, here is how I'm signing the code:
/usr/bin/codesign --resource-rules desktop-app/target/dist/myApp/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp
find desktop-app/target/dist/myApp.app/Contents/ -type f \( -name "*.jnilib" -or -name "*.jar" -or -name "*.dylib" \) -exec codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose -f -s "3rd Party Mac Developer Application: XXX" --entitlements desktop-app/target/dist/myApp.app/Contents/myApp.entitlements {} \;
codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp.app/Contents/Resources/binaries/ffmpeg
codesign --resource-rules desktop-app/target/dist/myApp.app/Contents/ResourceRules.plist --verbose --force --sign "3rd Party Mac Developer Application: XXX" desktop-app/target/dist/myApp.app/Contents/MacOS/JavaAppLauncher
We've had a java app on the MAS since late summer 2012. I think we were the first java app on the store (more info at infinitekind.com).
I think one issue is how you are signing. To be accepted on the app store you'll need to bundle a JDK. This can be done using the appbundler ant task. We've created a fork of this with a few improvements since the official one seems to be stagnant and not accepting updates:
https://bitbucket.org/infinitekind/appbundler
We've also created a fork of the OpenJDK with a couple of minor fixes that were dealbreakers (menu item keyboard shortcut issues) for us. These may now have been incorporated into the mainline OpenJDK, but I don't think so.
https://bitbucket.org/infinitekind/openjdk7u-jdk
Anyway, the above two items may not be necessary in your case, but that's how we did it and it worked. I think the real problem is what you are signing and in which order. Here's what we do and it's been accepted for five update submissions now:
# sign all the jar and dylib files (signing jars is apparently not required by apple, but should be!)
find "Path/To/App/AppName.app/Contents" -type f \( -name "*.jar" -or -name "*.dylib" \) -exec codesign -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' {} \;
# Sign the JDK plugin
codesign --verbose -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' "Path/To/App/AppName.app/Contents/Plugins/jdk"
# sign the whole bundle
codesign --verbose -f -s '3rd Party Mac Developer Application: YourCompanyName' --entitlements 'path/to/AppName.entitlements' "Path/To/App/AppName.app"
Hope this isn't too late to be helpful!

OTHER_CODE_SIGN_FLAGS keychain flag ignored?

I have just learned about the possibility to use OTHER_CODE_SIGN_FLAGS to specify the keychain which includes the cert needed for building and signing an app. But unfortunately I cannot get it to work.
My script looks something like this:
#!/bin/bash
TARGET="MyProject"
CONFIGURATION="Release"
SDK="iphoneos"
IDENTITY="iPhone Developer: John Doe (XX22RR22O)"
KEYCHAIN="/Users/username/Library/Keychains/someKeyChain.keychain"
PASSWORD=""
security unlock-keychain -p ${PASSWORD} ${KEYCHAIN}
xcodebuild -target "${TARGET}" -configuration ${CONFIGURATION} -sdk $SDK CODE_SIGN_IDENTITY="${IDENTITY}" OTHER_CODE_SIGN_FLAGS="--keychain ${KEYCHAIN}"
But that fails:
Check dependencies
[BEROR]Code Sign error: The identity 'iPhone Developer: John Doe (XX22RR22O)' doesn't match any valid certificate/private key pair in the default keychain
But if I switch to the keychain first it works but that is not useable on a build server where multiple builds could happen simultaneously:
#!/bin/bash
TARGET="MyProject"
CONFIGURATION="Release"
SDK="iphoneos"
IDENTITY="iPhone Developer: John Doe (XX22RR22O)"
KEYCHAIN="/Users/username/Library/Keychains/someKeyChain.keychain"
PASSWORD=""
security unlock-keychain -p ${PASSWORD} ${KEYCHAIN}
security default-keychain -s ${KEYCHAIN}
xcodebuild -target "${TARGET}" -configuration ${CONFIGURATION} -sdk $SDK CODE_SIGN_IDENTITY="${IDENTITY}" OTHER_CODE_SIGN_FLAGS="--keychain ${KEYCHAIN}"
Hope you guys can help
-Morten
I found that if I didn't add the keychain to keychain search list, xcodebuild would not respect the OTHER_CODE_SIGN_FLAG --keychain setting. I had to add this code:
// Early in the script
ORIGINAL_KEYCHAINS=`security list-keychains -d user`
// After I create my keychain, add it to the list
security list-keychains -d user -s ${ORIGINAL_KEYCHAINS} "${KEYCHAIN_NAME}"
// On cleanup
security list-keychains -d user -s ${ORIGINAL_KEYCHAINS}
Needless to say, I lost hours figuring this out.
Also of help, making sure the keychain stays open for the length of your build. As advised here:
security -v set-keychain-settings -lut 7200 ${KEYCHAIN_NAME}
The answer is to upgrade: Xcode 4.3 respects the OTHER_CODE_SIGN_FLAGS flag during the Check dependencies build step.
I ran into the same problem while trying to set up CI for our iOS projects. I ended up updating the PackageApplication Perl script to support passing a keychain option. Location:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
I'm still waiting for some licensing clarification from Apple so that I can publish my updated script to GitHub.
None of these really works unless you have the simplest of scripted builds going. Like #Tyler said, PackageApplication doesn't support specifying the keychain, and some versions of xcode will require there be no duplicate certificates across keychains when they check dependencies.
Don't waste your times, just call Apple and ask them to rename one of your certificates (they will actually rename your company --- by appending a suffix --- and you just have to regenerate your certificates and update your profiles).

Command /usr/bin/codesign failed with exit code 1

CodeSign "build/Release-iphoneos/Nice Saying123.app"
cd "/Users/c28/Documents/Office Projects/Nice Saying123"
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
setenv _CODESIGN_ALLOCATE_ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
/usr/bin/codesign -f -s "iPhone Developer: dipak kasabwala (29QJU3WV6X)" "--resource-rules=/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app/ResourceRules.plist" --entitlements "/Users/c28/Documents/Office Projects/Nice Saying123/build/Nice Saying123.build/Release-iphoneos/Nice Saying123.build/Nice Saying123.xcent" "/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app"
/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app: replacing invalid existing signature
/Users/c28/Documents/Office Projects/Nice Saying123/build/Release-iphoneos/Nice Saying123.app: CSSMERR_TP_NOT_TRUSTED
Command /usr/bin/codesign failed with exit code 1
I had the exact same error, and tried everything under the sun, including what was on the discussions.apple.com link above. What the problem was for me was that in Keychain Access, the actual Apple WWDR certificate was marked as "Always Trust". It needed to be "System Defaults". That goes for your Development and Distribution certificates, too. If any of them are incorrectly set to "Always Trust", that can apparently cause this problem.
So, in Keychain Access, click on the Apple Worldwide Developer Relations Certificate Authority certificate, select Get Info. Then, expand the Trust settings, and for the combo box for "When using this certificate:", choose "System Defaults".
It's very confusing that selecting "Always Trust" produces an error claiming that something is not trusted :( ... but that's the way it is apparently!
Hattip to #MariaZverina, whose comment/link provided help on this issue.
Edit: you may need to check both Login and System certificates, looking for this problem.
Even I had tried everything everywhere :) but what Nate says is true, it works :)
Just make sure you check both login and system certificates , mine had the System certificates set to Always Trust, making me overlook them.
Apple Code signing authority and Apple Worldwide Developer Relations Certificate Authority.
my error was :
/Users/XXXXXXXX/Library/Developer/Xcode/DerivedData/XXXXXXXXXX-fictlumohhjzjxcfmyfpwvrjakqa/Build/Products/Debug-iphoneos/XXXX XXX.app: object file format unrecognized, invalid, or unsuitable
Command /usr/bin/codesign failed with exit code 1
Try below.
Development system : OSX Lion, Xcode 4.1 iOS 4.3
if you have copied a successfully archived project and modified it for a new version, the copied version may run fine in simulator. But Distribution archive may get the above error. It took a day for me to sort this issue.
Right click Your_Project.xcodeproj> Show package contents & edit project.pbxproj file.
Solution :
- The Info.plist file may be having more than two copies in the project folders. As well wrong/multiple references in configuration sections inside the pbxproj file. o I have deleted those lines except referring them from Build configuration(Distribution). Set the info.plist reference in project settings as below.
Finally check the distribution settings should be like this..
8917E65D14244E5100B703F8 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
ARCHS = "$(ARCHS_UNIVERSAL_IPHONE_OS)";
CODE_SIGN_ENTITLEMENTS = "";
CODE_SIGN_IDENTITY = "iPhone Distribution: XXXXXXXX XXXXXXX";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: XXXXXXXX XXXXXXX";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = XXXXX_Prefix.pch;
INFOPLIST_FILE = Info.plist;
IPHONEOS_DEPLOYMENT_TARGET = 4.3;
ONLY_ACTIVE_ARCH = NO;
PRODUCT_NAME = "Product Name";
PROVISIONING_PROFILE = "XXXXXXXX-XXXX-4ACA-A26E-XXXXXXXXXXXXX";
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "XXXXXXXX-XXXX-4ACA-A26E-XXXXXXXXXXXXX";
SDKROOT = iphoneos4.3;
SEPARATE_STRIP = YES;
TARGETED_DEVICE_FAMILY = 2;
VALIDATE_PRODUCT = YES;
WRAPPER_EXTENSION = app;
};
name = Distribution;
};
In my case, it turned out to be because neither of the necessary intermediate certificates were installed (Apple WWDR and Developer ID). I just set up a new computer and exported my developer profile from my old machine, which bundles up all of the necessary certificates, keys, provisioning profiles, etc. into a single file, making a neat little package that can be backed up, or in my case, easily moved to a new machine. Unfortunately I had assumed that the intermediate certs would come along for the ride. They didn't. Downloading the intermediate certificates from the Apple developer site and installing those using Keychain Access did the trick.
Note there are two intermediate certificates: the Apple WWDR Intermediate Certificate (which covers both iOS and Mac App Store development and distribution), but there is also a separate Developer ID Intermediate Certificate (which covers Developer IDs, e.g. distributing outside of the App Store).
This occurred for me after another certificate was added to my keychain.
This is a senseless fix, but having tried everything, I unlocked/locked the login keychain and everything was fixed.
hmmmm.
In my case it was the "iPhone Developer" certificate which was marked as "Always Trust". After switching to "System Defaults" it works like a charm! :-)
I also was able to make it work by selecting "System Defaults"