I have a code cert that is going to expire soon and have recently acquired a new cert from the same provider. I need to transition my android app from the older cert to the new cert. However because the certs are different android requires a full uninstall (deleting app data which I would prefer to avoid).
Due to my client specification I'm unable to use a self signed cert.
Is there a way to transfer without losing the local app data?
I am aware at adt -migrate exists but when I use it I get the following error
Migration certificate can only be applied to desktop native installers with native extensions. Target: apk
Extending certificate validity should be your first choice.
Let your CA extend your certificate instead of purchasing a new one.
All certificate information will be preserved and your clients won't need to uninstall the app at all.
Is there a way to transfer without losing the local app data?
No, other than by backing up the data, uninstalling the old app, installing the new app, and restoring the data. If your app does not already have a full backup mechanism, then you are in a world of hurt, if you cannot get the CA to extend the certificate (per flx's answer).
Due to my client specification I'm unable to use a self signed cert.
That does not change the fact that you need a signing key that will live long enough for the lifetime of the app. And, since certificate authorities do go out of business, so your client should buy a suitably-long certificate now, rather than assuming that an extension can be obtained at any point in the future.
Or, your client should come to its senses and use a self-signed certificate.
Related
I would like to get the list of all revoked certificates list downloaded on an Android device? I know that this class allows you to check if a certificate is revoked or not, but I want to get the whole list of revoked certificates. Is it possible? Does Android store such a list or it uses OCSP to check the certificates?
It would appear that Android does not store a certificate revocation list (or at least if it does then it doesn't use it). There's a reddit thread from a few years ago that brings this up and discusses the pros/cons of it, but the essence of it is that if you go to https://revoked.grc.com/ (which should throw an error if your browser checks for revoked certificates) on mobile Chrome, you'll be notified that your browser doesn't check for revoked certificates.
From the page above (revoked.grc.com, which you shouldn't be able to see unless you're using a browser without a CRL):
The mobile Android platform currently offers no certificate revocation checking of its own, so Android apps (including all users of Google's Chrome browser) are vulnerable to malicious certificate abuse. The only way to use Android securely today is with Firefox, which brings along its own certificate security.
A couple more sources I found (again a few years old, but they still seem to be relevant and accurately describe the current situation):
An issue on the OkHttp (an Android http client) github discussing whether to add certificate revocation checks, where they decide not to
The CommonsBlog, discussing the lack of certificate revocation checks on Android
A Chromium issue about the lack of a CRL, where one of the developers states that it won't be added and presents the justification:
Marking this WontFix for two reasons:
1) Revocation checking is the responsibility of Android and the related SSL APIs. Android itself does not and has never performed revocation checking [...]
2) Revocation checking generally doesn't work (as a security feature), and especially for mobile, greatly affects performance (negatively) and privacy (negatively)
Now that lets encrypt.org launched public beta, they are only giving away https certificates that last 90 days. Thats for security reasons and they advice the developers to renew their https certificates after 60 days and the best way to do that is to automate that.
However, I am looking to be adding HTTPS to my mobile app. How would you automatically renew a certificate every 90 days? Wouldn't that require a new app build and an update every 60 days to the app/play store?
I would love to see this question answered because I realize HTTPS is much more secure.
Thanks in advance!
Didn't have enough space in comment so I'll post it here
I'm not really sure how encrypt.org is working, so as long as you don't provide some more information about their certificate system I cant help you.
However X509Certificate itself, contains mechanism to certificate renewal, so if it's implemented correctly on ther side you can actually implement it in your app:
According to wiki:
To allow for graceful transition from the old signing key pair to the
new signing key pair, the CA should issue a certificate that contains
the old public key signed by the new private signing key and a
certificate that contains the new public key signed by the old private
signing key. Both of these certificates are self-issued, but neither
is self-signed. Note that these are in addition to the two self-signed
certificates (one old, one new).
Since both cert1 and cert3 contain the same public key (the old one),
there are two valid certificate chains for cert5: "cert5 → cert1" and
"cert5 → cert3 → cert2", and analogously for cert6. This allows that
old user certificates (such as cert5) and new certificates (such as
cert6) can be trusted indifferently by a party having either the new
root CA certificate or the old one as trust anchor during the
transition to the new CA keys
However this still require for you to have CA cert, (which probably you don't).
On the other hand I don't know why you need your own certificate (and why from encrypt.org)? And are you sure, that their certs are not validating in Android default TrustStore? And eventually Isnt's it better to create self signed certificate for you server and use it in app so you can have full control?
Can anyone give me a hint if it is possible to ask Android to include (or 'trust') additional Root CA in their OS ( which will be updated during next update and pre installed on the new instances)?
At this moment each website which use SSL certificate for https which is signed by our Certificate Authority is asking for trusting this website by showing
untrusted connection warning
Of course installing certificate manually solve the problem, but this is not the case considering number of operation which user has to make in order to use the website without concerns that he is being attacked by some kind of men in the middle attack.
For the record we have pass audits made by the independent organizations.
Root Certificate Policy - The Chromium Projects says:
If you are a root CA, the following contacts should be used:
...
Android: Please file a bug at
http://code.google.com/p/android/issues/entry . Note that, similar to
Linux, the certificates included within the Android sources may be
further altered by device manufacturers or carriers, pursuant to their
local programs.
I am wondering which is the more popular option, Having 1 keystore to sign all the apps you publish, and duplicating that keystore into the cloud and locally to keep it safe, or generating a new keystore for every new app submitted, and keeping copies of all of them?
It seems easier to have 1 keystore for everything, but despite duplicating it, im afraid of it getting corrupted and loosing access to all of the apps.
Whats the best approach for this situation?
If you use the same keystore, it will be easier to make your apps work together. By having them signed with the same key, you can use a shared UID (not really recommended), or use signature based permissions. That would make it possible to export certain data or functionality and restrict access to your own apps only (using a ContentProvider or a remote service). The downside is, that if you loose the key, you'll have to republish all apps.
If you use separate keystores, it's easier to transfer an app to someone else (give them keystore and password). Additionally, you need to re-publish only one app if you lose/corrupt the keystore.
Take you pick, but I'd say: use the same keystore and make lots of backups. I would also use physical media (CD, etc) in separate locations, rather then the 'cloud', but that's your choice too.
My objective:
Create an EAP WiFi configuration - including the CA Certificate - in Android programmitcally.
Problem:
How do I install a CA Certificate programmatically (and then reference that certificate in the EAP WiFi configuration)?
I found a very useful link already that allows me to create and save EAP WiFi configurations here:
How to programmatically create and read WEP/EAP WiFi configurations in Android?
However this assumes that you have already installed the CA Certificate on the device. I would like to install the certificate within my app - either from the resources in the app, or sent from a server.
Is this even possible? (Rooting is not an option in this case.)
If so, how?
Additional info...
I also found a way to add a certificate to a KeyStore:
https://stackoverflow.com/a/4490543/1172101
However this is used specifically for creating a secure socket and connecting via HTTPS. I want to use the certificate for WiFi.
Unfortunately, I have yet to find a way to install a CA Certificate programmatically - from within the app.
However, it is possible to install a certificate via the Web browser in Android. Thus, the solution (for now) is to:
Launch an intent to open a URL in the Web browser that goes directly to the CA certificate.
This works but there are some challenges:
The user must name the certificate. This is a challenge because we are adding the WiFi configuration programmitically. Thus we have to ask the user to give the certificate the same name.
The user must enter a password. If they don't have a password set up, the user will create one and enter it twice. If they have set a security password, the user will have to remember that same password and enter it.
Assuming the user successfully completes these steps, he is left hanging in the browser.
This leads to a few questions:
From my app, is there a way to force a name for the certificate that the user installs via the browser?
From my app, is there any way to know when the certificate installation has completed and then give focus back to my app?
Just let me know if you need any clarification.
You cannot install it directly since non-system applications don't have access to the key store. On ICS, there is an API for this KeyChain.createInstallIntent() that would launch a system dialog asking the user whether they want to install the certificate. On pre-ICS you can achieve the same thing by launching the install intent using the component name directly (this may or may not work on all devices though). Going through the browser is actually a roundabout way of doing the same thing.
As for your questions:
you cannot specify/force a name. Why do you care about the actual name?
Not really through the browser. If you use the system intent, you can return to your activity and will get a callback if you use startActivityForResult().
Update: Android 4.3 has WifiEnterpriseConfig which both creates a profile and installs keys and certificates in the system credential store. You only need the CHANGE_WIFI_STATE permission.
I am currently looking to solve the same issues. The best thing that I have found is KeyChain.choosePrivateKeyAlias() allowing the user to select which certificate to use for the SSL. From there you can retrieve the Alias name and pass it to the enterprise wifi configuration.
I'm looking for the same... as for your question, #Nikolay:
you cannot specify/force a name. Why do you care about the actual name?
The EAP profile needs the name of the already-installed-CA. If you look at the example in part 4, you can specify:
final String ENTERPRISE_CA_CERT = "";
In the example, the profile does not use the CA name, but that could be the case for other EAP profiles.