Forum Discussion
Mobile Apps, internal use, certificate warnings
Hi,
We are currently deploying Skype for business mobile apps for internal use.
Before that, the use of mobile apps was mostly external. No problem...
But it appears that by using applications internally, users receive many warning related to the fact that internally, certificates are signed by the Active Directory Certification Authority.
In BYOD scenario, we can deploy our root CA to device, not a problem, but for some population, mobile are only used as "mobile Lync Phone", and when you deploy root CA to android phones, you are required to set an unlock code. This is not compatible with the intended use.
Is there a way to prevent this ? After a lot of reading I have find a discussion saying that you have to redirect ALL https connections like meet.domain.com, including desk phones, windows clients, etc..., to reverse proxy, like that it's our public certicates that are presented to mobile.
This seems to me completely absurd and at least not optimized
So what is the good practice for Mobile Apps using internally with internal certs from ADCS ?
Thanks
28 Replies
Nick ElniffMicrosoft
Is it possible to purchase public certs for the internal SfB Infrastructure?
This is really the best route to take and will eliminate a lot of headaches if you want to provide the full feature-set for BYOD SfB Mobile clients that are on your internal network.
Yes, possible and done that. And some organization who prefer to use Public cert for all secure communication over internal cert.
I had configured and deployed public SSL certificates for Frontend, Oauth, RP, and Edge for a few customers and working perfect.
Please let me know if you wanna know how it should be done.
- Hi Benoit,
Mobile apps are using the dns records lyncdiscover.domain.com for login in.
Desktop clients are using in first case lyncdiscoverinternal.domain.com.
Recommendation is to point A record lyncdiscoverinternal.domain.com to front end server/pool. lyncdiscover.domain.com A record should point to the reverse proxy, in this case the external webservices url will be used (port translation 80,443 to 8080 4443).
There is documentation on technet about how mobility needs to be configured.
link: https://technet.microsoft.com/en-us/library/hh690030(v=ocs.15).aspxHi Erwin,
currently I don't have lyncdiscover.xxxx record on our internal DNS.
But it's not what I understand here :
When you use Automatic Discovery, mobile devices use DNS to locate resources. During the DNS lookup, a connection is first attempted to the FQDN that is associated with the internal DNS record (lyncdiscoverinternal.<internal domain name>). If a connection cannot be made by using the internal DNS record, a connection is attempted by using the external DNS record (lyncdiscover.<sipdomain>). A mobile device that is internal to the network connects to the internal Autodiscover Service URL, and a mobile device that is external to the network connects to the external Autodiscover Service URL. External Autodiscover requests go through the reverse proxy. The Lync Server 2013 Autodiscover Service returns all Web Services URLs for the user's home pool, including the Mobility Service (Mcx and UCWA) URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Lync Server 2013 Mobility Service externally through the reverse proxy.
For me, it tries first to lyncdiscoverinternal, and as soon it will find it, it will connect to it.
After it should use external web url. but if it uses another url, like meet.domain.com, etc, internal DNS will always send it to front end server, and we will have problem with certificates.
- Mobile devices don't connect to internal Autodiscover Service (will use internal certicate). This is only used for Desktop Client. Like Ivan mentioned UCWA request will land on Reverse proxy and will be forwarded to Skype external web services url(public certificate which the mobile phone can check), this one is using port 8080 and 4443 (in default configuration).
