I want to replace the SHA-1 certificate fingerprint number (A) with the SHA-1 certificate fingerprint number (B) in the Google Play Console. How can I do that or edit/delete the one I want to replace?
I already tried to upload a new version build but that didn't let me change the SHA-1.
You cannot do that. The certificate used to sign an application cannot be changed. That's because your app could not be updated on your users devices if you did so. Either whitelist this App Signing certificate on all APIs you are using so that your app works with it, or you'll have to delete the app and recreate it, decline enrolling in App Signing initially, then enroll later if you wish to create a separate upload key.
Related
So, i am making a flutter app for my client. For uploading the app on playstore am generating the
upload key(.jks).I want to know whether on generating the key for the playstore can anyone take any important content from that key. Like can someone use that key to get data from my laptop or misuse it in any form. Is it safe to generate the key then upload app on playstore from your laptop and then give key to the client?
The JKS file will contain the key and a certificate associated with the key:
The key is only two or three very long numbers.
The certificate associated with the key contains information such as Name, Company, Country, etc. (which you should have been prompted for when you created the certificate).
The key and certificate will only allow the client to sign future APKs/Bundles to upload to the Play Console, that's all. So yes, it's safe to give the JKS file to the client (assuming it was created just for that app).
I can`t find valid signing identity in target settings. After i requested signing identity from XCode->Preferences->Accounts menu (see picture), my identity is revoked always. And after i relaunch xcode, i've not any signing identity for my distribution provision profile. I tried to remove ALL stuff from keychain, re-create distribution certificate and provision profiles, but anythings doesnt work. Previously i successful saw iOS Distribution identity with status Valid on my another mac, but i can't upload binary from it. Maybe i should delete something from Mac, where identity is valid?
Click + button to create new iOS Distribution. And if you provide whats the result, would be perfect.
if xcode didnt correct or create new one. Do it on member center developer.apple.com. Then you should be able to see it.
I am creating an application which is like a template where every service provide can enter their details in the setting on the web and just change the app name ,app icon, new bundle identifier and upload the app on app store.
Till here it was good, But the problem for me is that I have a push notification services in this app.
And I have read on the apple document that every bundle identifier should contain a unique push certificate. And from there we create a .pem file, so that means every app will have a different- different pem file.
But I want a single pem file which will work for all app.
Can anybody please suggest me what should I do, or what is the proper way to go about it?
Unfortunately, what you are asking for is not currently possible with Apple Push Notifications Service. Though you could conceptually use several of the optional arguments in openssl to generate a Certificate Signing Request (CSR) using the exact same keypair, the root issue comes from the 'Certificates, Identifiers, and Profiles' tool in the very first step in creating a new APNS certificate:
As the supplemental instructional text reads: "Note that only explicit App IDs with a specific Bundle Identifier can be used to create an [sic] Push SSL Certificate", which means that we can neither provision a Wildcard App ID for push notifications, nor can we specify 'All App IDs'.
If we briefly step into a hypothetical world where the "Which App ID would you like to use?" question doesn't exist and instead went directly to the step where we upload our CSR, the certificate we would get back from Apple would do exactly what you want -- It would authenticate the server you use to construct APNS payloads as one legitimately belonging to you and authorized to send pushes to the APNS Gateway. It does, however, open an important security concern -- If you can use this one server (or 'provider' in APNS parlance) to send pushes to any of your apps (so long as you know the device's APNS token), what prevents you from using your provider to send pushes to my apps? Or if we turn the concern around -- what would prevent me from using my authorized APNS provider to send your apps push notifications? Or to send pushes to your customers with misinformation (ex. 'Regrettably MyApp is closing its doors and exiting the App Store. MyApp recommends customers purchase CompetitorApp to maintain your service!'). This slimy, scam-prone world we thankfully don't live in...
Instead, Apple requires 3rd-party developers to select the AppId for which payloads from a particular APNS certificate will be honored. Then even if I somehow manage to acquire your customer's app's device token, I won't have your server's private key and thus could not successfully deliver a scam, spam, or otherwise rogue APNS payload to your customers.
Ok, I got it already! Since I can't use a single certificate for multiple App IDs, what can I do?
Given some of the background in your question, it sounds like you've put in the effort to make your app highly configurable. In your own words "[it] is like a template" - which would suggest that on the server-side of your app, you have some mechanism in place to be able to be able to identify what app is making data requests and which provider's data to send back. Your APNS Provider logic would need to have similar intelligence built in. Depending on how you are currently making these server-side distinctions, you may be able to reuse some of the existing logic; you are the one who will have to make that call. The remainder of this answer will offer a high-level approach to how you might choose to setup your provider owing to the one-pem-per-app requirement APNS imposes. In general:
Place a copy of the signed .pem in a secure location on your APNS Provider
Update your Provider's 'register device token' API to accept both the device token as well as some way to uniquely identify the app for which this token is valid (...maybe as simple as just the App ID itself!)
Update the iOS App to pass both it's APNS device token and that App Identifier to the freshly updated 'register device token' API on your provider.
Update your Provider's logic to use the correct .pem when delivering a payload to the APNS Gateway.
For the sake of good process, ensure that you have a procedure to update or retire an application's .pem, data, and relevant tokens.
For each app that you make from your template, you already have to generate a unique App ID and App Store Distribution provisioning profile. When doing this initial setup, you can also request the APNS certificate and treat all three pieces of data as app-specific settings. Install the APNS certificate into your provider along side the .pem file for your other apps so that you can grab it when it comes time to send an APNS payload to Apple.
If you've done APNS work before, you know that your provider is responsible for tracking app-specific device push tokens, generating and transmitting the APNS payload to Apple, and optionally using information from the APNS Feedback API. When your app connects to your provider to register its token, you'll also need to know for which app that token is valid so that you can select the right .pem for sending APNS payloads. This is key; if you don't have a way to know which tokens go with which App IDs then you will be unable to select the right .pem file during payload generation and dispatch.
Updating and retiring software is a key part of all software, but is one that doesn't always get the attention it should. Make sure you've considered how you'd go about refreshing the .pem file (which you'll have to do each year before the current one expires) as well as how you'd go about retiring an application without disrupting the other apps your provider services.
The answers to each of these questions is very much dependent on how you've architected the various components of your app, Xcode project configurations, server-side technologies, and server-side logic. Only you, or your team, can make the right call based on the details that make up your software. Best of luck and let us know how things go.
I'm building an iphone app that needs to access a web service over https using client certificates. If I put the client cert (in pkcs12 format) in the app bundle, I'm able to load it into the app and make the https call (largely thanks to stackoverflow.com).
However, I need a way to distribute the app without any certs and leave it to the user to provide his own certificate. I thought I would just do that by instructing the user to import the certificate in iphone's profiles (settings->general->profiles), which is what you get by opening a .p12 file in Mail.app and then I would access that item in my app. I would expect that the certificates in profiles are available through the keychain API, but I guess I'm wrong on that.
1) Is there a way to access a certificate that I've already loaded in iphone's profile in my app?
2) What other options I have for loading a user specified certificate in my app? The only thing I can come up with is providing some interface where the user can give an URL to his .p12 cerificate, which I can then load into the app's keychain for later use, but thats not exactly user-friednly. I'm looking for something that would allow the user to put the cert on phone (email it to himself) and then load it in my app.
I've tried with this:
NSString *thePath = [[NSBundle mainBundle] pathForResource:#"certificate" ofType:#"p12"];
NSData *PKCS12Data = [[NSData alloc] initWithContentsOfFile:thePath];
CFDataRef inPKCS12Data = (CFDataRef)PKCS12Data;
CFStringRef password = CFSTR("pass");
const void *keys[] = { kSecImportExportPassphrase };
const void *values[] = { password };
CFDictionaryRef optionsDictionary = CFDictionaryCreate(NULL, keys, values, 1, NULL, NULL);
CFArrayRef items = CFArrayCreate(NULL, 0, 0, NULL);
SecPKCS12Import(inPKCS12Data, optionsDictionary, &items);
inPKCS12Data is correct but items is empty. What is happening?
I've done this for a recent app by making the documents folder for the app accessible via itunes. Our users are then instructed to drag their generated key (in a p12 format file) into the documents panel for our app in iTunes. When the app is started, it checks for the existence of the p12 file and, if it exists, imports the file into the keychain.
It's not the simplest procedure, but it is the most secure because you don't have a private key file being sent around via email.
If a .p12 file isn't too big you could encode it using Base64 and then embed a link in an email with a custom url scheme, e.g.:
myapp://certificate/<base 64 data>
User clicks the link, your app saves the certificate somewhere for future use. Just make sure that Mail.app on the iPhone won't mangle the email.
Apple does restrict the use of device-wide keys/certificates to it's own applications/services, such as WiFi, VPN, Mail, etc. Third-party applications are not able to use any of these keys/certs (without jailbreaking). However, applications are able to import, store, and use keys and certificates in a in-app keychain. In addition, you can share keys/certs across multiple applications with the keychain-access-group feature in iOS.
I recently published a blog post titled In-App Mobile Certificates Made Easy with mCMS, which may have helped you out. Our company is developing an API that makes it easy to support in-app certificates, obtained directly from your Microsoft-based PKI. Our solution also offers on-device key generation, instead of generating a P12 on another machine and trying to import it into your app.
If you're using AirWatch for app distribution, their SDK provides the ability to provision certificates from your Certificate Authority to your registered devices. This allows you to provision your certs, and then access them from your app's code.
Does the code suggested in Finding a Certificate In the Keychain work for you?
Oh man, this brings up painful memories from October/November 2009. I was able to successfully get client-side certs to work but I had to port libcurl to the iPhone (which wasn't easy since the NDA was still in effect at the time).
I haven't done iPhone app development in over a year so I don't know how much is changed, but if I were you I'd first try to get by without client-side certs and if you absolutely must have them you can use libcurl with PEM formatted certs.
I am trying to verify the user identity on my application using a certificate / identity that the user has stored by opening a .cer / .p12 attached to an email. The certificate appears on the settings app of the phone under the group "Configuration Profiles".
Is there any way of accessing the certificate using the iphone SDK (I have tried to use the Security Framework, but it seems that it is only possible to access certificates stored in the application keychain or other keychains from its group)?
You talked about the Security framework already, but did you try the following functions in the doc?
I personally never tried/had to do this myself, but anyway it seems that there are some functions like SecCertificateCreateWithData in the framework, so you should be able to build a SecCertificateRef from some NSData/CFDataRef… data which is the content of your mail attachment.
From there you may use it as any other certificate using the other functions (like you would do for a certificate extracted from the Keychain)
Well this is only a guess after simply reading the documentation but let's give it a try as the doc seems to indicate it is the way to go.