I'm working with a liferay application that is hosted on a machine at 192.168.1.50:8443 with a self signed certificate (keystore was added to tomcat).
I now want to connect the API to an android app. This connection works in production, but I can't make it work in my local environment, even after accepting the certificate in chrome, and installing it to the android device, it is detected but gives me this error:
SSLPeerUnverifiedException: Hostname 192.168.1.50 not verified
But then it prints out the certificate being used and shows CN:192.168.1.50 and every parameter exactly as I set it. Can anyone give me some pointers of where to go from here? I have already tried everything I can find including injecting customized socket factories, hostname verifiers and SSL contexts.
Any help is appreciated, even if it is a way to trust all certificates I'll take it, I don't care about security, I just need this for development.
Related
We have recently needed to change our SSL certificate on our server. Our consuming application has suddenly stopped working. I had presumed this was to do with Java's cacerts, and modified the program to import the new certificate to each client, the problem was not resolved.
When the application attempts to load the remote view (shown below) on the server, it simply loads a white page. I have tried loading the page through http:// and it seems to function, however the rest of the application (including the API) requires https, and subsequent calls to the API fail (images loaded through https are showing as broken within the app).
The website is functional, and when I access URL's being provided to the app, through my desktop browser they load without issue. The app is also functional when I run it in Debug mode, these issues only occur when I use the "Run" build mode.
I have tried creating a blank MAF application, hoping it was some caching issue, however this new app also cannot load the remote URI. I have done a clean build and have tested other remote URI's (they work). I feel as if there is an issue with Java somehow not accepting the new certificate. The first time I tried to load the website within Eclipse's browser, an error displayed along the lines of "certificate revocation information". I didn't pay much attention to this error and it provided the option to install the new certificate, after which the page loaded within eclipse's browser.
In Jdeveloper there is an option of Disabling the Application Transport Security as shown in the image.
Could you try disabling in your eclipse too, Kindly refer this doc https://wiki.eclipse.org/Jetty/Howto/Configure_SSL, this might do a little help :)
The issue seems to be due to the changed SSL certificate on your server.
Short answer:
There was no chain installed, I installed the provided ca-bundle file and updated the httpd.conf file to reflect the chain location and the app now works.
Long answer:
When our server dev installed the new certificate, he neglected to install the ca-bundle (certificate chain) provided by the CA. The site was working in a browser, I can only assume, because it has a more complete list of trusted CA's built in. My best guess is that MAF requires the chain to be installed and was failing some security test, or the chrome webview it uses did not have this CA on the trusted list.
I am a newbie developing an Android app. It implements a socket connection and has to bypass or allow all host for it to work with our self-signed certificate installed on a server.
I heard that google play store doesn't accept this kind of connection in the published app. Is it true? Or there is another way to do it?
Thank you.
and had to bypass or allow all host in order to work with our self-signed certificate installed on server
That was not a particularly good move, from the standpoint of security.
I heard that google play store doesnt accept this kind of connection in the published app
The Play Store has implemented a ban on apps that bypass SSL validity checking and blindly accept all incoming SSL certificates.
Or there is another way to do it ?
Android 7.0+ has support for self-signed certificates. I backported that code to work on Android 4.2+. There are other libraries that offer self-signed certificate support, such as this one. There have been articles written on using self-signed certificates.
I've got an Android App trying to send HTTPS Requests to a server having a Symantec Class 3 Secure Server CA - G4 signed certificate.
When trying to send a request via the apache http library (I guess this is also true for other HTTP clients) an exception stating "No peer certificate" is thrown. The same requests to the same servers on iOS work fine and even if I connect to the server in chrome, running on the same Android device I'm testing on, it says the certificate is perfectly fine.
Now I heard that Google dropped trust for some Symantec certificates, but as far as I know only the ones with a 1024 bit key. The one in question is signed with a 2048 bit key. And Chrome also accepts it!
I also found this article [1] saying that I need to import the complete keychain as BouncyCastle keystore. The problem here is, that every user specifies the url to their own server, managing their own certificates.
So my question is: Is anybody familiar with this problem and knows a workaround? I found endless of guides showing me how to turn of certificate validation for a request ... but that won't be a solution working for me.
[1] http://blog.antoine.li/2010/10/22/android-trusting-ssl-certificates/
The problem I actually had was that the server required SNI (Server Name Indication) support on the HTTP client. Androids version of the apache http library does not support SNI. So I had to write my own SSLSocketFactory supporting it.
I've read a lot of articles regarding the import of a cert, but I am still unclear on a couple things.
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
I can install a client cert manually, but there is an expiration date. So I'll need to manage the expiration dates of all client installed certs on our application server, and take an outage to update each one.
It feels like there should be a better way.
Shouldn't the application automatically accept a valid signed cert? [In this case, it is signed by VeriSign]
We are getting an exception currently when trying to access an https url from the application without explicitly installing the cert.
The API proxy library is swallowing the internal exception, so I dont know the details.
If the cert should be accepted automatically, then there may be a different issue here...
Can a signed certificate be used without importing explicitly?
Yes, it does not need to be installed prior to use. In fact, if you know in advance of what to expect, then you can include that information into the application. That has an added benefit of improving the application's security posture.
To avoid importing the certificate, use a custom X509TrustManager and override checkServerTrusted. In checkServerTrusted, ensure the server's public key is expected (i.e., pin the server's certificate or public key); or verify the server's certificate is valid (i.e., is within validity and forms a chain to your trusted root).
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
In the case of client certificates, the server advertises the issuer whom it relies upon to issue client certificates. So the server will need to know the trust point for issuing client certifcates for authenticating clients.
In this case, it is signed by VeriSign
This could be really bad. In this case, you will trust all of your clients signed under the Verisign PKI, and all of Verisign's other clients signed under the Verisign PKI.
In this case, it would probably be better to avoid public CAs and run your own PKI (i.e., be your own CA). In this case, pick up a copy of Network Security with OpenSSL. The book will show you how to accomplish the customary tasks using both the openssl command and programmatically.
Say, I have a Java web app inside a war file that is hosted on cloudfoundry at the url mycoolapp.cfapps.io, which works perfectly. I now need to host it on a custom domain mycoolapp.com and I have purchased the domain.
What is process to host it on my own domain? Can I do it via Cloudfoundry?
My app needs ssl. Currently https://mycoolapp.cfapps.io works. But I need it to work on my custom domain. What will be involved in this? (I think I need to get a certificate for my domain, but what next?)
In the app some confidential information is embedded in urls (this cannot be changed), so I'd also need to ensure that the provider cannot know the urls accessed (apart from the base url). Can this be done? If not, what are the alternatives?
It could be done by creating a CNAME record for your app (see Azure example here). Unfortunately, it seems that Cloud Foudry (CF) does not support it yet. As I understand, it is caused by the fact that CF router determines the exact Virtual Machine (and, hence, IP) by parsing URL and determining the route according to the host name (mycoolapp in your case). Ideally there would be an interface in CF where you could register all CNAME aliases for your app (as implemented for Azure websites)
If CNAME record would be enabled, that it would also work for HTTPS, as it basically resolves IP address. And definitely there would be an interface for you to upload a certificate for your domain. This leads to problems mentioned below about SSL termination. But, again, as far as I know, it is not supported by CF yet.
That it a question to the internal structure of run.pivotal.io deployment of CF. Conceptually HTTPS will do the trick as it encrypts URL parameters. However I suppose that SSL terminates on the router (as certificate is issued for *.cfapps.io - single cert for all apps - you could check it in browser connection to your app by HTTPS). That likely means that internally CF has access to ALL data of your request, and leads to my question about SSL termination in CF, which currently has no answer. Hope CF will provide a way to terminate SSL on the final server processing the request.
UPDATE:
Cloud Foundry has proposed its own way to support custom domains - through using CloudFlare proxy. If the fact of using proxy that decrypts your data is Ok for you, it could be used.