I am trying to sign my APK file with keystore.jks file manually to publish my App on Google Play Store.
here are the commands I am following.
zipalign -v -p 4 com.VolMobileApp.Android.apk com.VolMobileAppAligned.Android.apk
apksigner sign --ks h2vkeystore.jks --out com.VolMobileAppRelease.Android.apk com.VolMobileAppAligned.Android.apk
Here is the issue. I tried to look for a solution but did not succeed.
When Second Command asks
Keystore password for signer #1:
After filling password it returns the error given below. Earlier there was no error.
Failed to load signer "signer #1"
java.io.IOException: Invalid keystore format
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:666)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:57)
at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:71)
at java.security.KeyStore.load(KeyStore.java:1445)
at com.android.apksigner.SignerParams.loadKeyStoreFromFile(SignerParams.java:353)
at com.android.apksigner.SignerParams.loadPrivateKeyAndCertsFromKeyStore(SignerParams.java:239)
at com.android.apksigner.SignerParams.loadPrivateKeyAndCerts(SignerParams.java:181)
at com.android.apksigner.ApkSignerTool.getSignerConfig(ApkSignerTool.java:368)
at com.android.apksigner.ApkSignerTool.sign(ApkSignerTool.java:291)
at com.android.apksigner.ApkSignerTool.main(ApkSignerTool.java:84)
I am not able to detect what I am doing wrong, but the difference I notice is in the archived folder structure.
In my case solved the problem by signing the .APK whit the values signed into the keystore that we configured to create the APK file in Release mode.
I taked the Microsoft example in here
and here I put the same values
That way a solved my problem with
"java.exe" exited with code 2
But the real information problem was in output:
Failed to load signer "signer #1" java.io.IOException: Invalid keystore format
At the moment I don't find the real solution to this problem but, this works.
Related
At present our android build export format is .apk format. I was able to successfully take apk build v1 & v2 signature. From Aug 1st 2021 onwards google discontinues .apk and need everyone should migrate to .aab bundle file. So when same keystore file I used to generate .apk file, I am getting below error
The security strength of SHA-1 digest algorithm is not sufficient for this key size
Detailed error message:
Execution failed for task ':app:signReleaseBundle'.
> A failure occurred while executing
com.android.build.gradle.internal.tasks.FinalizeBundleTask$BundleToolRunnable
> Failed to generate v1 signature
Is there a way to edit the key size of SHA-1 digest algorithm inside the keystore file?
Any other workaround for issue?[like disabling V1 signature]
You will have to create a new key.
I had the same problem. After I created a new jks keystore file I was able to sign the bundle. See here for how to create a new key.
I started a bash code that tries to download a file via axel, but when the script is about to download the file, it crashes and the error SSL error: certificate verify failed.
Can someone please help me with that, like adding an exception via command-line?
Part of the code:
axel ${EXTRAARGS} --alternate "https://build.nethunter.com/kalifs/kalifs-20171013/kalifs-armhf-minimal.tar.xz "
Other variables were already declared.
The result is:
Initializing download: https://build.nethunter.com/kalifs/kalifs-20171013/kalifs-armhf-minimal.tar.xz<br>
SSL error: certificate verify failed
Thanks anyway.
Did you try man axel? From the man page:
--insecure, -k
Do not verify the SSL certificate. Only use this if
you are getting certificate errors and you are sure
of the sites authenticity.
I'm trying to enable push notifications in my app, the problem is that I can't generate the certificate because whenever I upload my CSR (generated from Windows) I get the following error:
Invalid CSR Select a valid Certificate Signing Request.
The CSR was generated using the following specs:
Key Size 2048 bit
RSA Algorithm
I did the same process last year and I was able to generate the certificate but now all I get is the error above.. did Apple change anything about the CSR or am I missing something?
found it........
The CSR first and last line were:
-----BEGIN NEW CERTIFICATE REQUEST-----
.
.
.
-----END NEW CERTIFICATE REQUEST-----
I had to remove the NEW word and it worked, I was able to generate the .cer file
Got an alert on server that the certificate is going to expire. I click the "renew" button and it says Unknown Error. So I dig deeper and run the following on the command line
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/certadmin --recreate-CA-signed-certificate "macserver.local Code Signing Certificate" "IntermediateCA_MACSERVER.LOCAL_1" dd3d0ec3
to which i got the following error:
/Applications/Server.app/Contents/ServerRoot/usr/sbin/certadmin --recreate-CA-signed-certificate: Unable to renew identity 'macserver.local Code Signing Certificate': unable to renew certificate: could not find original certificate 'macserver.local Code Signing Certificate' with serial number 'dd3d0ec3' issued by 'IntermediateCA_MACSERVER.LOCAL_1' (-25300)
So I run the following to search the certificate and it does find it:
sudo security find-certificate -c "macserver.local Code Signing Certificate"
keychain: "/Library/Keychains/System.keychain"
class: 0x80001000
attributes:
"alis"<blob>="macserver.local Code Signing Certificate"
"cenc"<uint32>=0x00000003
"ctyp"<uint32>=0x00000001
"hpky"<blob>=0xA14502C168EB2D717615AA60535926B760804C8F "\241E\002\301h\353-qv\025\252`SY&\267`\200L\217"
"issu"<blob>=0x308193312A302806035504030C21496E7465726D65646961746543415F46494C455345525645522E4C4F43414C5F3131123010060355040A0C09727472616374696F6E312D302B060355040B0C244D41434F5358204F70656E4469726563746F727920496E7465726D6564696174652043413122302006092A864886F70D010901161361646D696E40727472616374696F6E2E636F6D "0\201\2231*0(\006\003U\004\003\014!IntermediateCA_MACSERVER.LOCAL_11\0220\020\006\003U\004\012\014\011macserver1-0+\006\003U\004\013\014$MACOSX OpenDirectory Intermediate CA1"0 \006\011*\206H\206\367\015\001\011\001\026\023mymacserver#gmail.com"
"labl"<blob>="macserver.local Code Signing Certificate"
"skid"<blob>=<NULL>
"snbr"<blob>=0x00DD3D0EC3 "\000\335=\016\303"
"subj"<blob>=0x30553132303006035504030C2966696C657365727665722E6C6F63616C20436F6465205369676E696E6720436572746966696361746531123010060355040A0C09727472616374696F6E310B3009060355040613025553 "0U1200\006\003U\004\003\014)macserver.local Code Signing Certificate1\0220\020\006\003U\004\012\014\011macserver1\0130\011\006\003U\004\006\023\002US"
Anyone have any ideas on this?
I've solved this problem for my cert. Instead of using hexadecimal, i use decimal. So in your case the serial number should be 3711766211 in decimal.
Hope this will help you too.
Thanks
When deploying an APNS certificate in a .wlapp file in MFP 7.0, I'm seeing a null-pointer exception when it validates the end-date, even though it has one. ( openssl pkcs12 -in apns-certificate-sandbox.p12 | openssl x509 -noout -enddate returns a valid date in the future).
It seems others have made this work, so I'm guessing it must be something I am doing wrong...has anyone else resolved similar issues with valid Apple Push Notification Service certs failing to be deployed on MFP
Relevant lines from the log:
947: "com.ibm.worklight.admin.services.ApplicationService E FWLSE3000E: A server error was detected.",
"948: com.ibm.worklight.admin.common.util.exceptions.ValidationException: FWLSE3119E: APNS certificate validation failed. See additional messages for details.",
"949: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:232)",
"950: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validatePushConfiguration(PushEnvironmentUtil.java:220)",
[ ... lots more trace here .. ]
"1030: Caused by: java.lang.NullPointerException",
"1031: at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:117)",
"1032: at com.ibm.worklight.admin.util.PushEnvironmentUtil.getCertificateExpiryDate(PushEnvironmentUtil.java:362)",
"1033: at com.ibm.worklight.admin.util.PushEnvironmentUtil.validateApnsConfiguration(PushEnvironmentUtil.java:230)",
Initial hurdle was that the .wlapp file was not being built, so no apns certificate was in the file (it is just in .zip format with a meta directory that should hold the .p12 file). The underlying issue was that the tag's password field in application-descriptor.xml wasn't exactly right: it was following the example from "Push Notifications in iOS applications" at https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/notifications/push-notifications-native-ios-applications/ :
<pushSender password="apns-certificate-p12 password"/>
when it really should just have the password:
<pushSender password="password"/> </code></pre>
with the file named either apns-certificate-sandbox.p12 or apns-certificate-production.p12 depending on which server is to be used.
Double dumbass on me for not checking the official docs at http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/devref/c_the_application_descriptor.html , which has it described correctly.
Moral: "When in doubt, RTFM"