I was trying to connect to a https back end service from the Worklight adapters in my local pc for the my app.
But I was getting the below error, then I posted a question Making web service calls to a HTTPS server from Worklight Adapter - javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Runtime: Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
I followed the steps given here
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/topic/com.ibm.worklight.help.doc/admin/t_ibm_worklight_server_and_self-signed_certificates.html
and imported a self signed certificate in the java cacerts keystore of my system and the adapters started working. Wow!!!
Now, I have deployed my adapters over a WAS and followed the same steps, imported the certificate there also, but I am still getting the error when I try to use the adapters.
First of all note that WAS has its own JRE with its own keystore that needs to be updated.
Also, if you're using recent release of WL the usage of self signed certificates within WL adapters became much simpler - http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.installconfig.doc%2Fadmin%2Ft_configuring_SSL_WL_adapters_backend_servers_certificates.html
Related
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.
I have used an external api which can be accessible via https (sha1 ssl), And now the external api system upgraded to sha2. While I am hitting the api, i am getting below exception.
Connecting to test.demo.com|10.200.100.101|:8443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish `SSL connection`.
Update:
Comments from external api team (earlier we used SSL protocol and now TLS (TLSv1.2) is benign used in new setup (SSL was expired protocol)).
Based on description above (without actual code snippet) you need to check if you client application has appropriate protocol specified (if they changed it on server to TLS v1.2, you need to change it in your client as well). Great link regarding different TLS versions.
We have a HTTPS RESTFul service running in IIS. We are able to successfully call it using the browser. However, when we call the service from a worklight adapter, we are getting the following exception:
"javax.net.ssl.SSLPeerUnverifiedException"
The worklight adapter was working perfectly fine when we were using HTTP instead of HTTPS.
We have followed all the steps mentioned in the documentation:
Create certificate using keytool in the IIS server. Bind it to the RestFul service.
Exporting the public key to a .cert file
Importing the file into Worklight keystore
Mentioned https as the protocol in the adapter.xml.
We have even verified the default.keystore of the worklight, it is matching with the certificate present in the IIS server.
We don't need mutual authentication. We just want to use SSL in the RestFul service deployed in the IIS.
Thanks,
Pavan
You forgot to add the certificate to your device's trust store. Since it is self signed, devices will not trust them by default. To do so, follow the steps here for your device's OS: http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/c_ssl_config.html?lang=en
Specifically, look at this for iOS and this one for Android.
Recently, my Test Worklight server has been configured and secured via https protocol and SSL setup (CA certificate is added).
However, my mobile app cannot connect to the WL server now and get an error. Before, it can connect to the WL server normally with http protocol.
I did some tests (exmaples for Auto Provisioning and Custom Provisioning - module_25_0_CustomDeviceProvisioningCustomProvAppAndroid) based on the Device_Provisioning_concepts.pdf document, but they didn't work on Test env.
I think it should be that some settings were not configured successfully, so that WL server didn't issue the certificate to the mobile app. I am not sure.
Any idea?
Information:
WL servsion: 5.0.6.1, Enterprise Version;
Not install the App center mobile application firstly, just install MyApp via the web url of App Center;
Hybrid application
[ERROR] [https://serverhost:9443/demo/apps/services/api/AuthDemo/iphone/query] Host is not responsive.
As Anton said, the certificate is not being trusted by the mobile device. The reason you get a 'Host is not responsive' error is because the SSL handshake failed because the device did not trust the server's certificate, so an HTTPS connection was never created, and it interprets it as if it did not find the server, because the SSL handshake occurs at a lower level than HTTP, and it cannot distinguish between both cases. If you want to see the SSL errors, you will have to use a program like Wireshark or Charles to look at the network traffic.
If you want to use this untrusted CA certificate, you will have to manually import the CA certificate to the device's trusted certificate store so that the device trusts . This varies from platform to platform. For example, on Android and iOS, you can email the certificate to the device (it has to be in .crt format), and then when you open it, the device will let you import the certificate. After manually trusting the certificate, the application should work.
Try to open Worklight console from you device's browser. Most probably it will notify you about invalid certificate (popup and/or icon in the address bar). In case it does - the certificate you've purchased is not trusted by mobile phones. You should ask CA for a certificate trusted by Apple/Google browser.