We have the MobileFirst platform running on our Linux machine. Business Logic Web services are running on a separate Server. The Certificate is issued by our Business Server.
We have overwritten the MobileFirst certificate mfp-default-cert.crt with the certificate issued by our Server. This certificate is used to establish the HTTPS SSL connection between the MobileFirst adapter and the web service.
We have successfully integrated this encrypted web service (using SSL) between MobileFirst (using HTTP Adapter) and Server in a Native app.
Now we want to implement/configure SSL connection between Mobile Device/emulator and MobileFirst server for secure communication using the same issued certificate.
Can anyone please advise how to do that?
As we know for SSL Connection, there should be a proper handshake to happen between the server and client.
Client(Device/Emulator) which you are trying to connect with server should have a corresponding CA Certificate installed on it so that it will have a successful secured communication with sever machine .
so you should have the client side certificate(example.crt) installed on your device/emulator to connect the server on HTTPS port.
And it depends even on the Device u are using to connect .
For iOS devices from 9.0. Apple mandates more secure way of connection
https://developer.ibm.com/mobilefirstplatform/2015/09/07/preparing-ibm-mobilefirst-platform-server-app-transport-security-ios-9/
Hope this serves your purpose. :-)
Related
We have some ethernet devices (iot project) communicating with our cloud based servers. Connection goes over SSL.
The device is using Global Sign R2 as Root CA. After google managed SSL certificates got updated few days ago, it felt out of chain of trust and the device cannot connect anymore.
Is there anything we can do on the backend side to allow the device to connect? Any source of SSL certificate with R2 in chain? I know it will expire soon, but we need to have it running just temporarily. Once the device connects, we will be able to upload new certficiates, but now it's dead. Any hints?
You can download and install the GlobalSign R2 certificate here:
Google Trust Services Repository
We have an application running in WAS 8.5 server. The application has two external Service invocations, hitting 2 different third-party systems, in which one Service (Service2/Server2) requires Client Authentication.
Please refer the diagram for reference.
Server2 <-- Client --> Server1 Handshake Diagram
For Server1, we have shared a Client Certificate with them and the handshaking is perfect.
For Server2, which doesn't required Client Aunthentication, fails during handshaking. What we could find out that, during handshaking the server tries to authenticate the Client (Assuming that Client Authentication is SUPPORTED at Server2, but not REQUIRED). Since the Client KeyStore has the Client Certificate, it's being used for handshaking process, which is failing because this client certificate is not present at the Server2 Truststore.
My question is, whether is it possible to not send the Client Certificate to the Server2 even if the Server supports Client Authentication.
Hope this question is understandable.
Note1: We don't have any control over Server1 or Server2 and we don't expect any changes from these third-party Services to make this work.
Note2: Service2 works perfectly without Client Certificate in the Client Keystore. Please refer the diagram for Serer2-Client SSL Handshaking, which is perfectly working.
Client --> Server2 Handshake Diagram
Expecting help from someone who is proficient in Websphere SSL configurations.
Thank you,
Sanooj
In short:
You have to create 2 separate dynamic outbound SSL configs (see here for details) assuming your 2 external services have different URLs. The one that needs CertAuth will have cert in the keystore, the other will not have (you need 2 different SSL Configs).
I have the following implementation in testing environment,
Front-end Server [IBM HTTP Server + IBM Websphere plugin],
WLServer1 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1] and
WLServer2 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1].
plugin-cfg.xml has been generated from each Worklight server and merged.
The request[http] from multiple devices has been directed to worklight server's alternatively, once the merged plugin-cfg.xml has been deployed in Front-end server's IBM Websphere plugin.
How I can implement the same to serve HTTPS request.
And also I have implemented the "UserCertificateAuthenticationProject" from the Worklight modules which connects the device[HTTPS] to Worklight server directly.
Note Tested it on Android only.
Help me to understand, How I can achieve HTTPS in Test environment via IHS.
What should be the procedure in Production environment?
Note IBM Worklight 6.2 supports Android, IOS, Blackberry & Windows, so I have to implement in all platforms.
It sounds like the problem you are having is similar to this one: https://stackoverflow.com/a/21914147/2245921 The Unresponsive Host error occurs for one of two reasons:
Your device cannot reach your server (they are not in the same network)
The device does not trust the server's certificate
Since you can connect to your HTTP connection, it is not #1, so it should be #2. The answer to the other question I pointed to above should fix your problem. Make sure to turn on trace-level logs in the WL Logger so that you can see the exceptions regarding untrusted certificates.
Edit: To expand on this answer; to use HTTPS, your server needs an SSL certificate to identify itself, otherwise the device has no proof that it is connecting to the right server and not to some random server that could be malicious. You should already have a certificate that you are using in your server; if you don't, then read on.
You usually get an SSL certificate from one of two places: you either use a certificate issued to you by a trusted Certificate Authority (e.g., Verisign), or you create one for internal testing purposes. In your case, you probably want to create your own, so you should follow the "Client X.509 Certificate Authentication and User Enrollment" getting started here, specifically the parts that talk about generating the server certificate.
Once you have that certificate set up, you should configure your server to use it; for that, follow the instructions here. After doing this, the last step is to have your device trust your server's certificate. For this, follow the last part in the getting started above, which shows you how to make your iOS/Android device trust the server. You would have to look up how to do this on Windows and Blackberry, too.
After this, you should now be able to connect successfully via HTTPS. (Always make sure that when you get an "Unresponsive host" error, that you can still connect to the HTTP console via the browser, to make sure that you are connected to the same network as your server. I know you already did this as you specified in your question, I'm just mentioning it as a reminder since it is easy to forget this.)
I have an application which can access a LDAP server with non-SSL connection. Now, the LDAP server has been configured to support only SSL.
So, now what are the new components or changes in the existing components which I have to do.
If your application really doesn't support SSL (btw it would've made things easier if you'd told us what program you're trying to use), you can try an SSL wrapper, such as stunnel that can be configured to connect to the SSL-protected LDAP service whenever your program connects to the "entrance" of the tunnel. This way, your program doesn't have to support SSL, but your connection to the LDAP server is still secured by SSL (if the SSL wrapper runs on the same host as your program).
You should only have to change ldap: to ldaps: in the client.
My client failed her PCI compliance audit. The server supports Remote Desktop (Terminal Service) but only provides encryption and not authentication. This exposes the server to Man-In-The-Middle attacks.
The supposed solution is to force SSL as the transport layer for RDP.
Anyone know how to do this?
The server runs Windows 2003.
The 'old' RDP indeed does not perform authentication, but I'd be careful using SelfSSL proposed in the link sent by #ig0774 (the rest of the data in the link is correct!) If authentication is what you care about, then have your client get a real server authentication SSL/TLS certificate from VeriSign or Thawte or someone else listen in the list of Windows trusted CAs.
I somehow doubt PCI will allow self-signed certs. But I'm happy to stand corrected!