Not gonna go into details about what I'm attempting to achieve here (which is not really about writing programs), but when using an existing Android app, I hit a wall which translates to the following in ADB logcat:
javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
It seems like the app somehow won't trust the remote server, so I searched for solutions to bypass this, but as far as what I've seen, the results are all about how to work around it when you're developing, i.e. when you have the source code of the app itself. The situation here is that I'm never going to have the privilege to get the source for the app, so what I'm looking for is a solution that can work around it for an existing app. An app/plugin to do this is okay, or even a way to reverse engineer the APK I have and add in the stuff I need - you say it, people upvote it, and I go learn it.
Thanks for your time for reading through a newbie's first question here!
javax.net.ssl.SSLPeerUnverifiedException: No peer certificate
It seems like the app somehow won't trust the remote server,...
No peer certificate means that the server did not send a certificate at all. So the usual methods of ignoring the result of the certificate validation will not help, because if there is no certificate there is no validation. Since the application seem to expect a certificate this looks more like a misconfigured server.
Related
Could you suggest how to add a self-signed certificate on Android (MIUI 12, Android 10).
There is a mobile app for Android, and a backend written in symfony. We have a bug that is very difficult to catch, and it is not clear whether it is a bug in the app or a problem in the backend. Currently, it is not known which endpoints in which order the mobile app calls. When I test my local backend through postman, everything works as expected (there is no bug). When I test on Android (which is directed to the stage), I can see a bug. Hence, it was decided to build the application directed to local backend by replacing the api-url with the hostname of my laptop. Then the requests would go over the local network to the local backend, where it would be possible to debug what exactly is happening. But once we've built the app, it turned out that it's not that simple to send requests to the local backend since a self-signed certificate is used. I tried to add this certificate to the android config, but nothing changed. Though, certificate shows up in the list. Maybe I made some mistakes when converting that certificate (because xiaomi doesn't allow to import a .crt file), or maybe it's backend that is configured incorrectly.
Can anyone who has encountered such a problem tell me how to set the environment up correctly. Maybe there is some guide on this topic.
PS. It is not an option to use Ngrok, because it will be necessary to distract the mobile team every time in order to build the application with the new url.
I'm developing an Android App which requests a server with https. So the server has a certificate. During development I've managed to trust all certificates to not care about that at this stage of the project.
As I'm preparing the production phase, I would like to know how do I use volley with https, by verifying the authenticity of the server. Should I import something in the App ? May someone explains me how it works ?
Please don't give me just a tutorial to follow, I've found some already but I'm facing difficulties to understand the process, some explanations would be great !
Thanks a lot !
As long as the certificate comes from a valid Certificate Authority (CA) it will work as is.
This is the same with all android https connections.
You do not need to install certificates etc on the android device.
(You should double check the CA you are using is valid on the android as there are some that may not be compatible this easily. Although the majority should be)
I know that this particular topic was asked many times, but unfortunately in my case none of them are working. For past few days I was trying to get it to functional state, but I failed every time, so I finally come here to ask.
I have a webservice on server with self-signed certificate. I can access wsdl file if I enter address into browser. Browser just remind me, that there is some issues with cert. and if I hit continue, everything works. Sadly I know very little about SSL, because its first time I made an application with SSL communication. In application I'll only get exception "No peer certificate" or "Trust anchor path not found" depends on type of "solution" I used.
I ran test on sslhopper.com and I get a warning that "The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate." Is this a serious issue in Android development or it could be resolved by some code?
So my question is actually, how can I do in application make "hit the continue button" or anything to make it actually connected to the server. In this case is it problem with certificate itself or am I doing something wrong on the application itself?
If you are trying to do client authentication, you need two things:
the CA certificate that issued the server certificate
a client certificate for your app.
You have to put 1. in the trust store and 2. in the keystore for your app. The sample code expects a PCKS#12 as the keystore, do you have one? What files have you been given? At this point it might be good to read the JSSE reference so you have an idea how the system works:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
I use ksoap2 to access a webservice. Everything was just fine before to change the test webservice with production one, witch use a https protocol.
I know that this question was asked few more times here, on stackoverflow, but none of the answers work for me. When I use ksoap2 with https I got this error (exception):
Not trusted server certificate
Someone provided and answer (solution) here: Android ksoap2 via https but I don't understand how to implement that solution (or the proposed solution is not working for me)
The certificate used by WS is a self issued ssl certificate - I use the application only inside a small company, but the company system administrator requires encrypted connection.
Can someone provide a better explanation for this issue?
Thank you.
I had a similar problem. Basically, when using Http related classes with the https protocol, Android will check with its installed certificates(which I believe are stored in the os keystore).
Because your certificate is self-signed, the certificate is not trusted.
I added my self-signed certificate to my app for testing purposes(alexander.egger's answer at How to install trusted CA certificate on Android device?). Maybe you can use this approach?
I guess Vedran's approach at Android ksoap2 via https does a similar thing and should work too. What part of that answer is unclear?
However, I dont think these are good solutions.
For my production environment, I ordered a (cheap) ssl certificate from a signing authority trusted by all Android devices and installed it on the server. I am not going to advertise here, but most commercial ssl certificates are trusted by all android devices, and it should be easy to find a cheap one with some research. I think this is the best solution to this problem.
Without a proper ssl certificate, your server would be untrusted to the entire world except your particular app, which is probably not a good solution(what if you extend to an ios device, a third party application calling the webservice,etc..).
I'm working on a server side solution for a mobile application written in Ruby. Part of our requirements is to notify our distributed clients to phone home to receive updated payload which Google's C2DM service seems ideal for.
I've already prototyped and tested everything we need and verified that the solution will work from my local machine. (Using the C2DM library for Ruby, the link is to my own fork in progress to solve an SSL certificate problem where the cert doesn't cover Google's api subdomain.) Except for one major hiccup in Google's ClientLogin API:
When deploying to our development application servers I was unable to transmit messages. Digging deeper into the results I found out that we were receiving a reply from Google that said CAPTCHAREQUIRED and a captcha token plus a URL to a captcha image despite the fact I was using a valid auth_token I created locally during development. So I used my own browser to request the CAPTCHA and solve it, then used curl to post the reply from our development server to ClientLogin after which I was able to get the auth_token necessary to transmit messages.
This had me worried that when deploying to a production environment a similar authentication challenge will occur. So a teammate and I performed some more research and found out that while no one knows the exact specifications as to when an auth_token may expire there is at least one purported Google engineer who claimed they are valid for "at least two weeks." Then a suggested solution is that when the ClientLogin response indicates CAPTCHAREQUIRED that you page/email an ops/devops person to solve the CAPTCHA and use a page/tool in your server application to submit the answer to get a new auth_token. (If this is what I have to do, I guess Amazon's Mechanical Turk saves the day?)
There is, of course, the real possibility that this information is outdated but that doesn't change the fact that I still need to solve CAPTCHAs at least during initial installation. We control the production environment so this isn't a very big deal, just a minor inconvenience since we don't know what, exactly, causes a CAPTCHAREQUIRED challenge response. (We theorize that its a previously unknown IP address for the account.)
I can't help but thinking I'm doing something terribly, terribly wrong here.
The question of auth token lifetime is still very much in the air. C2DM is officially still a beta, so the Google people don't want to commit to a solid figure. Understandable, but frustrating.
That said, in my experience, if you use a dedicated Google account for C2DM purposes, the CAPTCHA challenge never comes up.