I'm currently working on a project that must be a platform signed system app to be privileged to communicate on the I2C bus of a proprietary Android device.
The manifest contains android:sharedUserId="android.uid.system" and the resulting unsigned apk is signed, zipaligned and installed with this batch...
java -jar signapk.jar platform.x509.pem platform.pk8 unsigned.apk signed.apk
zipalign -f -v 4 signed.apk aligned.apk
adb install -rg aligned.apk
This works fine. However, I need to do extensive development running with this privilege requiring the debugger to be attached. I have tried using a custom Configuration that retains the debugger symbols while including the Mono runtime in the package only to find out that you cannot attach to an already running Android app from Xamarin.
Is there a way to create a keystore that is signed with the platform signature that I could put in ...\AppData\Local\Xamarin\Mono for Android\ to replace debug.keystore? The idea being that the debug build-deploy process would pick this up and I'd have the privileges I need AND have attachment to the debugger.
Any help much appreciated.
You can create a JKS keystore from a DER-encoded PKCS #8 private key and the corresponding PEM-encoded X.509 certificate as follows:
openssl pkcs8 -inform der -in platform.pk8 -nocrypt -out platform.key
openssl pkcs12 -export -in platform.x509.pem -inkey platform.key -out platform.p12
keytool -importkeystore \
-srckeystore platform.p12 -srcstoretype pkcs12 \
-destkeystore platform.keystore \
-deststorepass android -destkeypass android
shred -u platform.key platform.p12
For those following, after I performed the steps from Alex, I added this to the .csproj file to get Visual Studio to use it for this specific example.
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>(path)\platform.keystore</AndroidSigningKeyStore>
<AndroidSigningStorePass>android</AndroidSigningStorePass>
<AndroidSigningKeyAlias>1</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>android</AndroidSigningKeyPass>
</PropertyGroup>
Related
I am trying to open p7s files by command line, using openSSL with this line
openssl.exe smime -verify -in 1.pdf.P7s -noverify -inform DEM -out 1.pdf
openssl smime -inform DER -verify -noverify -in 1.pdf.p7s -out 1.pdf
But I am always getting this:
Verification failure
7100:error:04091068:rsa routines:int_rsa_verify:bad signature:crypto\rsa\rsa_sig
n.c:220:
7100:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:crypt
o\pkcs7\pk7_doit.c:1041:
7100:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:crypto\pkcs7\p
k7_smime.c:353:
And generating a file I can't open.
Later edit: I found out that "A p7s is just a signature file in DER format. There is no "content" in that file, it's normally apart of a S/MIME message as a base64 attachment." but I still don't know how to get the base file.
Yeah, it seems that the version I've used (1.1.1) is giving me this error.
Changing it an older version (1.0), it's working.
Searched all the questions related to recover keyerror, got no answer on my situation.
So, I just have several simple operations:
install jmeter 4.0 (on centos 7)
cd to the bin directory, run ./create-rmi-keystore.sh and pressed Enter in each steps(entered a password 123654 at final step), and finally it gives me
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore rmi_keystore.jks -destkeystore rmi_keystore.jks -deststoretype pkcs12".
Copy the generated rmi_keystore.jks to jmeter/bin folder or reference it in property 'server.rmi.ssl.keystore.file'
so I run keytool -importkeystore -srckeystore rmi_keystore.jks -destkeystore rmi_keystore.jks -deststoretype pkcs12 and give a password 123654
It gives me:
Enter source keystore password:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect
Can anybody give a hand, Thanks advance:)
solved by this , to answer the question What is your first and last name?, you'll have to reply with rmi which must be a corresponding value with server.rmi.ssl.keystore.alias in jmeter.propertise.
I know how to view the expiration date of an .ipa file's provisioning profile (by renaming the ipa to zip, then unzip it and view the ExpirationDate key in the embedded.mobileprovisioning file).
But how can I view the expiration date of the certificate itself that was used to sign the ipa?
I found that you can use the codesign utility to "extract" certs:
codesign --display --extract-certificates /Applications/Example.app
This produces three files: codesign0, codesign1, codesign2. Not sure how to proceed after that.
Do the following:
unzip -q MyApp.ipa
$ codesign -d --extract-certificates Payload/*.app
$ openssl x509 -inform DER -in codesign0 -noout -nameopt -oneline -dates
After doing the above, you will get output with:
notAfter=Aug 4 16:08:00 2017 GMT
This is the certificate expiration date.
I am creating PEM file for Production APNS , and i have done this several time before .
But i am facing an error on terminal while testing my PEm file from below command :
$ openssl s_client -connect gateway.push.apple.com:2195
-cert myCert.pem -key myKey.pem
It gives me :
Verify return code: 20 (unable to get local issuer certificate)
as response.
I have tried so many times but did not identify the problem .
May be it is because of my distribution certificates created on diffrent Mac .
But i am not sure .
Any help suggestion will be helpfull.
The developer link asks to include -CAfile server-ca-cert.pem, which does'nt work either.
All other options of indicating the CAfile gave me errors like 'unable to load certificate'.
The below actually worked for me after trying other options.
openssl s_client -connect gateway.push.apple.com:2195
-cert myCert.pem -key myKey.pem -CAfile entrust_2048_ca.cer
This solution gives 'Verify return code: 0 (ok)'.
On an additional note: You can also specify the .key file as the -key value & it will work too i.e. something like, ref here
openssl s_client -connect gateway.push.apple.com:2195 -cert myCert.pem -key myprivatekey.key -CAfile entrust_2048_ca.cer
You need to give a CA certificate as CAfile commandline argument to s_client. The trusted root certificate for the push servers is the Entrust CA (2048) root certificate which you can download from Entrust's site.
$ openssl s_client -connect gateway.push.apple.com:2195
-cert myCert.pem -key myKey.pem -CAfile entrust_2048_ca.cer
For more information and other possible reasons, please, check Apple developer guide Troubleshooting Push Notifications.
So, I've been looking around a lot of how to create a p12 file for iPhone development, and I think I'm doing exactly as I am supposed to, but at the last step I get some errors that are more or less impossible to decipher.
I am running Windows 7, and these are the steps I do:
1) Create the private key. I do this by running this command (cmd is opened in Administrator mode):
openssl genrsa -out mykey.key 2048
2) Create the CSR file
openssl req -new -key mykey.key -out developer_identify.csr
3) Upload the csr file to the iPhone dev site. Here I do the following:
Click on menu Identifiers --> App IDs, select the correct App ID, click Edit, click Create Certificate, click Continue, select the CSR-file created above and proceed. Wait for the site to tell me its all OK, and then download the *aps_development.cer* file.
4) Create the PEM file:
openssl x509 -in aps_development.cer -inform DER -out
developer_identity.pem -outform PEM
5) And lastly, create the p12 file (and this is where it fails):
openssl pkcs12 -export -inkey mykey.key -in developer_identity.pem
-out iphone_dev.p12
The output after the last command:
Loading 'screen' into random state - done
Enter Export Password:
Verifying - Enter Export Password:
8216:error:060740A0:lib(6):func(116):reason(160):NA:0:
8216:error:23077073:lib(35):func(119):reason(115):NA:0:
8216:error:2306C067:lib(35):func(108):reason(103):NA:0:
8216:error:23073067:lib(35):func(115):reason(103):NA:0:
The p12 file is 0 bytes.
The PEM file looks alright, starts with
-----BEGIN CERTIFICATE-----
then a lot of jibberish and then ends with
-----END CERTIFICATE-----