Is a signed SSL certificate required for Worklight development? - ibm-mobilefirst

Question

I'm working on a demo in Worklight version 6.0 where I need to use SSL from iOS and Android to the Worklight Server.
Is there any way to use a self-signed or test certificate in the Worklight server? Or do I need to buy a certificate from one of the standard CAs even for test/demo?
I've seen references to how to import my certificate in the Android system trust store, and that looks promising, but I'm not seeing anything equivalent for iOS. There are a number of native code workarounds (which net out to disabling SSL certificate verification altogether) along with much discussion about which solution works/doesn't work (and no discussion of what still works on iOS 7 that I can find).
Is importing the certificate into the Android system truststore the best approach for development?
Is there a simple solution for iOS that allows for self-signed or test certificate that doesn't disable certificate checking entirely?

Answer 1

OK. I didn't find a general purpose answer, or a way to accept a particular certificate, but on iOS and Android, it is possible to disable client side certificate validation for development and test.
In Android, the default Manifest is already configured to ignore certificate validation. By default, the Application element in AndroidManifest.xml has an attribute:
android:debuggable="true"
With this setting, the client does not validate the SSL certificate presented by the server. So on Android, self-signed certs just work by default. The important thing to keep in mind is that when you move from development to production, it is important to set this attribute to false. When the attribute is set to false, the client validates the cert presented by the server, and so you will need a real signed cert for the production server. (makes sense)
In iOS, there are several proposed solutions, The one I'm using is to add the following to the end of my < App Name >.m file:
#implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
#end
From what I gather, this is a unpublished API, and overriding it is bad form, but it works, and this is only for development, so I'm going with it.
I suppose I could be clever, and check for the hostname of my Worklight Server before blindly returning YES, but in any case, the addition of the code above does allow my app to use SSL with a self signed cert at the worklight server.
Both of these "solutions" need to be removed before the app is put into production, as they leave the app vulnerable to a man-in-the-middle attack. But for development/early test/demo they allow SSL without having to get real signed certificates.

Answer 2

There is a very easy way to use certificates not signed by a known CA for development and test purposes.
Note that this support does not come from Worklight. It is really up to each mobile platform to allow you to establish trust for these type of certificates or not. The recommendations given by David above, are really just workarounds to disable SSL validation, which could be a valid alternative in some cases. However, the android:debuggable flag will only get you so far as it doesn't cover certain scenarios like when directUpdate is enabled. Plus disabling all forms of SSL validation, may not be what you really want even in dev/test environments.
Here is what you can do:
First understand that pure self signed certificates won't work on iOS and Android, just because the platforms themselves do not allow you to install these type of certificates into their truststores.
Use self signed CA certificates instead. These are just as easy to create. They are the same as self signed certs except that they have the CA bit enabled to TRUE.
Beware, that self signed certs generated by some tools do not usually create certificates that are also CAs. Ensure your self signed cert is a CA as well.
OpenSSL example on how to create a self signed CA cert:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
Ensure the certificate.crt file is X.509 version 3, and has the following extension defined: basicConstraints = CA:TRUE
You can check the certificate.crt file by running the following command:
openssl x509 -in certificate.crt -text -noout
Use this certificate as your server certificate.
On iOS, e-mail your certificate.crt file or host the file on a web browser where you can manually click on it to install it. (Don't install it directly from the hosting WL server, as this only imports it into the browser space and not the device.)
Check that it gets installed by looking under Settings->General->Profiles->Configuration Profiles
Ensure iOS recognizes it and marks is as 'trusted'
On Android you can install the certificate.crt in the Android CA Store. The certificate.crt can be placed in /sdcard, and can be installed from Settings > Security > Install certificate from SD card. The certificate can also be opened by sending it as an email attachment or downloading via browser as in step 7 above. Android asks for an alias for the certificate, choose any name.
Check that it gets installed by looking under Settings -> Security -> Trusted Credentials ->User

Answer 3

Yes, you can achieve this by doing the following:
Create a self signed certificate that will act as a certificate authority.
Install this certificate on the iOS device (easiest way for me to do this was to host the certificate on a server and visit the link in safari and then download it). The iOS device will now trust any a server with a certificate that has been signed by this certificate authority
Create a new certificate that is signed by the certificate authority you created in step 1.
Use this newly signed certificate on your Worklight server

Answer 4

Currently Worklight App not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.