I want to describe a specific situation in specific Lync environment where was a problem with Lync mobility. There was a few misconfigurations and I will describe them below.
I created also a topic on technet forum about it
https://social.technet.microsoft.com/Forums/office/en-US/492f7d00-4896-40f6-a356-ca864f0ea12f/mobility-cannot-sign-in-android-display-self-signed-certificate?forum=lyncdeploy
Even if it is not supported by Microsoft we use wildcard certificate for Lync and all Lync services are able to work both internally and externally.
I did a lot of troubleshooting steps before find it out like Test-CsMcxP2PIM and another Test-Cs cmdlets, also get logs from mobile devices but the errors were not descriptive enough for me. Finally I found that lyncdiscoverinternal.domain.com was actually resolved from external DNS because we have wildcard\"catch all" DNS setting for our domain. So we changed it and now lyncdiscoverinternal.domain.com is resolvable to some "fake" ip address 1.1.1.1.
Then there was a few misconfigurations on IIS ARR configuration described below.
On IIS ARR there are URL rewrite rules - there must
not be rules for http, only rules for https are needed. I had an issue that there was a rule for http with wildcard and it catch what should not be caught also there was a checkbox selected "Stop processing of subsequent rules"
To troubleshoot it enable "Failed request tracing" on IIS under default web site on reverse proxy and look at rule names
Next mistake was to have defined server with external web services URL under IIS ARR Server farms. External web services URL is basically nor resolvable on reverse proxy - this is desirable situation. Server name should be specified as internal FE server name or FE pool name.
Next mistake was specified additional lync.* pattern with Match All setting as shown below. It was never true so trying to use another URL rewrite rules.
Then take a look also for server health: IIS ARR -> Server farms -> select specific farm and click Monitoring and Management. Health status must be health. It was unhealthy for me as I did some health checks before.
What helps me also was trying to access
https://ExternalWebServicesURL.domain.com:443/certprov/certprovisioningservice.svc
on computer (web browser) which was not domain joined and externally (not in corporate LAN). When You access this address You should get logon window and You should be able to authenticate providing user credentials