I'm getting the above mention error when my client update their device to iOS 7.1, and then try to update our app from the AppCenter.
After some searching, i found a post with a similar problem here. But then since i'm in an environment where by the client is using AppCenter to update the apps, i can't be using USB to plugin and install the app for them.
Is there any workaround for downloads via AppCenter until a support is released?
A change was introduced to iOS as of iOS 7.1 that requires OTA application installation to take place over HTTPS (rather than HTTP), and no provision exists to allow the user to continue to accept the old behavior (i.e., to permit application installation over HTTP). It is my understanding that this was done as a security enhancement.
In order to do application installations on iOS 7.1 from Application Center, you would need to configure your Application Center to use HTTPS rather than HTTP, using a certificate that will be accepted as valid by your iOS device - that is, either issued by a recognized public CA, or issued by a private CA that you have set up your mobile devices to accept. You can find more information about how to perform this configuration here:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.installconfig.doc/appcenter/c_ac_ssl_config.html
I would add some details. (Just work out this question)
We use self developed app center for our customers, to distribute demo/report apps.
You need SSL certificate. (see the post above)
You can buy any kind of public certificate . In some cases you can use self signed certificate previously installed on iOS device by Apple Configurator.
It seems that you don’t have to use https everywhere. Secure URL (https) must have a link to .plist only. The app center web site url and package .ipa url can still be under http.
… and shame on Apple that invents new ways to make developer life hard.
Related
I want to be able to expose my local machine address to the internet to be able to work with:
Google OAuth2 flow;
Receiving Push-Notifications for changes in my calendars/events;
So that, I need some tool that will expose my local machine URLs to the Internet so Google will be able to use this web hooks.
I found that ngrok with basic(5$) subscription works for me. Free versions doesn't work since I need SSL as it's required by google:
This is your Webhook callback URL, and it must use HTTPS. Note that
the Google Calendar API will be able to send notifications to this
HTTPS address only if there is a valid SSL certificate installed on
your web server. Invalid certificates include: • Self-signed
certificates. • Certificates signed by an untrusted source.
• Certificates that have been revoked. • Certificates that have a
subject that doesn't match the target hostname.
The question is whether there is something else I haven't taken into account that will force me to buy more expensive type of subscription? Maybe some specific requirenments from Google that basic subscription can't work with.
Basic $5 subscription works perfectly. It fits all Google's requirements + it provides static URLs that make it possible to receive PUSH notifications even when you restart your ngrok or computer.
I'm currently using Google Earth Pro 7.3.0.3830. I'm trying to access our KML feed behind an https link. The web server is using a self-signed cert that has a self-signed user cert associated with it (same CA). On Windows, I have the CA cert in the trusted windows store as well as the user certificate (both show up in chrome and IE). If I use the Google Earth plugin within Chrome, I can create a network link with https and access the feed. If I use the stand alone Google Earth app, I can't access it (red dot on the folder).
If I change the web server to allow http access and change the feed link, it displays fine on the standalone Google Earth app, (but using just http isn't desirable).
I can't figure out how to get Google Earth to use the client certificate to authenticate the https request to the web server. This is an issue for running Google Earth Pro in both Windows 10 and Centos 7.
Thanks in advance.
Please use Google Earth Pro 7.3.1.4507. It has the required ssl fix.
Please refer release notes
https://support.google.com/earth/answer/40901?hl=en
Based on the release notes for 7.3, SSL client certificates aren't supported in Google Earth Pro 7.3. I'm not sure, but the older versions may have support for them which you can download here.
We are using Mobilefirst 7.1 for hybrid application. We have implemented certificate pinning in the application. The certificate got expired and we replaced it with the new one. But the application is taking old certificate from Application cache and it is blocking the application to connect to server. After we remove the app cache and app data the application is working fine. Kindly suggest any solution for this?
Can you check if you have kept the same public key as before. Otherwise you will have to release a new version with the renewed certificate. Check this link for further details
I'm working on the application that uses REST web service with SSL. The web service is already in place, identifying itself with the SSL certificate. Even though the certificate seems to be valid, it is still being rejected by iOS. Below are the details:
Web service presents the certificate chain consisting of 3 certificates, the root certificate that is present on this list, the intermediate certificate and finally the web service certificate
The method - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)space is called each time I send requests to the web service. The comment in RestKit code says "server is using an SSL certificate that the OS can't validate", so I guess I should never reach that method, right?
I tried to access the web service from Safari on the test device, and the certificate is automatically accepted. The same goes for the desktop browsers.
Sslshopper says the certificate is fine.
I can connect to the web service by adding the certificate to the application bundle and handling it the same way I'd do with self-signed certificates, but I want to solve this the proper way. Any help greatly appreciated, especially if someone can point out why Safari on iOS accepts the cert, and my application does not.
Edit: it turns out that I've been using old RestKit version. I created the proof of concept that allowed me to dispatch some requests to my server, and with the RestKit master from today (3rd May 2012) the certificate is accepted. However, I get two calls to connection:canAuthenticateAgainstProtectionSpace:, in both of them I return NO, but it manages to connect properly anyway. So, the new question is, what exactly has changed in RestKit that I can connect properly now. I need to know this because I will have to patch the old version that I'm going to use for release. I will update RestKit afterwards.
Edit: I need to give that back to the RestKit guys, it was not their fault. The web service that I'm trying to connect to is using some kind of gateway which is the source of the problem. There were some fixes from the gateway crew earlier in the day, that's why it worked correctly by the time I managed to perform the tests with the latest RestKit version.
I had an idea for a fitness mobile app and I have been developing applications based on this idea for iPhone (Obj-C based), Android (java based), WebOS (html5 based) and Nokia Qt.
I now need to provide authentication to the users of my application. The server is a typical LAMP system. I would like the users of my mobile application to log in to the server seamlessly and securely.
I am not really a web programmer and hence would appreciate ideas on how I can go about providing authentication. I've heard about OpenID...but I am not sure if it can be used for authenticating mobile clients. Some one mentioned OAuth but I am not sure if a) it would work in this use case and b) What if my client does not have a Facebook/Twitter account?
Any ideas will be appreciated!
I have done something similar and used gnuTLS and a x.509 certificate to authenticate from the client side. Its seamless and easy to integrate.
https://idlebox.net/2009/apidocs/gnutls-2.6.6.zip/gnutls_7.html#SEC65
The important thing about using this method for me was that the https connection was just simple method calls and the handshaking process itself would be handled by the gnuTLS library.
My app was an iOS app and i used xcode to do it which was easy. I think it will be easier on the Java side but I am not sure about the Nokia part. The coding is in C and is thus cross platform.
However if you are looking for a iOS based solution i recommend http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html
But for a cross platform solution that would require the same certificate across all applications and no input or work fro the user, I still suggest gnuTLS and using the x509 certificate.
If you already have a LAMP server somewhere, it should be fairly easy to set implement your own API for password authentication -- the important thing is that you do it via HTTPS! (so the user-ids / passwords can not be sniffed). You will need a digital certificate (CERT) for your web-server.
On your LAMP system you can keep the user data in it's database. Your LAMP server should also allow to create a local user account (of course).
You can use this solution either separate or together with OpenID or OAuth!
That means, if your client doesn't have Facebook or Twitter, they can still create an account on your LAMP server.
http://en.wikipedia.org/wiki/OAuth