locked
Smartphone on internal corporate wireless joining using meeting S4B URL FAILS with certificate error !!! RRS feed

  • Question

  • We have a S4B enterprise pool fully working and mobility working fine with S4B smartphone apps externally and also on the internal wireless.  Now, when someone tries to join a meeting using the meeting URL provided in the meeting invite in outlook and the option to join via S4B app or web app is shown, if S4B app is chosen then the meeting join is all good as this by design goes from internal wireless to the rev proxy external side and public cert is used for meet.domain.com URL

    If the user on the smartphone chooses web application (browser) instead of S4B app, then this connection fails with a certificate error as it obviously looks for meet.domain.com etc. and this is resolved internally to the S4B pool directly (since on internal wireless) and the private cert is passed to smartphone which it does not trust.  Is there a way around this ? (aside from installing internal cert on all smartphone devices)

    Cheers





    • Edited by Dazzler1971 Wednesday, October 26, 2016 4:16 PM
    Wednesday, October 26, 2016 3:31 PM

Answers

  • Yep totally understand the issue here and the smartphone app works fine as it should on internal wireless via the rev proxy.  all good.

    But for the web app on the smartphone option, yes we have considered using a public CA for the FE servers but in reality I think it will be easier to install the internal cert chain onto the smartphones.

    TBH I dont see this as a massive issue for smartphones on internal wireless as if presented with the choice of S4B mobile app or web app then im sure most users will click the S4B mobile app for full functionality.

    Cheers I just wondered if there was a more up to date work around of this problem but clearly there is not.  

    Thanks guys :-)


    Hi Dazzler,

    For mobile client, it must use public CA, because it will join meeting from external.

    If there are any questions or issues, please be free to let me know.



    Best Regard,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Marked as answer by jim-xu Monday, November 7, 2016 1:55 AM
    Tuesday, November 1, 2016 6:42 AM

All replies

  • Hi Dazzler,

    Welcome to our forum.

    Did this issue occur on different smartphone?

    By this issue, we suggest you open Skype for business Deploy Wizard and re-run “Request, Install or Assign Certificate” as the following snapshot:

    If there are any questions or issues, please be free to let me know.


    Best Regard,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, October 27, 2016 5:41 AM
  • Thanks for the response but i'm afraid that is not going to work as the problem is not the internal certificate but the fact that the request from the smartphone on the internal wireless  will use internal DNS to resolve meet.domain.com and hence go direct to the FE pool and will be presented with the internally signed (PKI) cert which will not be trusted on a smartphone (since it is not a domain member).

    Any other ideas?

    Thursday, October 27, 2016 6:04 AM
  • Hi Dazzler,

    When clients connect from internal network, then meet.domain.com should point to IP of your reverse proxy. Here you can either just redirect to frontend pools without use of certificate or you can use 3rd part certificate.

    When clients connect from external network, then meet.domain.com should it your reverse proxy in DMZ zone with 3rd part certificate installed and used for authentication.

    In your case, you will have to install 3rd part certificate on your internal reverse proxy and not just redirect as it is defined today.

    Do you have multiple domains? You need meet for each domain in your certificate as well.


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you. Thank you! Off2work

    Thursday, October 27, 2016 7:03 AM
  • Totally agree with Off2work's reply

    When you connect using mobile client on internal network, mobile client would be trying to reach lyncdiscover.domain.com, lyncdiscoverinternal.domain.com. which would reach FE since internal DNS usually points these fqdn's to FE. Mobile client would get a JSON file as a response which contains External WebService URL, on which we need to connect further for Login process. External Webservice URL wont be available in internal DNS usually so the client finds it from Public DNS and connects through Reverse proxy, where it has a  public certificate.

    Please refer following link for in depth information.

    https://technet.microsoft.com/en-us/library/hh690030%28v=ocs.15%29.aspx?f=255&MSPPError=-2147217396

    Problem with meet url is same url is available on both internal and external dns, in internal dns its points to FE and in external DNS it points to reverse proxy.

    Since DNS is resolved in internal DNS, it wont even try to get External DNS details, try to connect to FE and give certificate error.

    Permanent solution would be changing CA used to create internal certificates for FE and other servers from Internal CA to a Public CA.

    Simple workaround would be adding trusted root certificate for internal CA in mobile device. I have tried it in Android and windows phones (I remember). Not sure about iPhone.

    you can Download CA chain from any system in domain by browsing http://internalcafqdn/certsrv

    Refer following link for instructions to import it on android

    https://support.google.com/nexus/answer/2844832?hl=en

    Thursday, October 27, 2016 7:36 AM
  • Yep totally understand the issue here and the smartphone app works fine as it should on internal wireless via the rev proxy.  all good.

    But for the web app on the smartphone option, yes we have considered using a public CA for the FE servers but in reality I think it will be easier to install the internal cert chain onto the smartphones.

    TBH I dont see this as a massive issue for smartphones on internal wireless as if presented with the choice of S4B mobile app or web app then im sure most users will click the S4B mobile app for full functionality.

    Cheers I just wondered if there was a more up to date work around of this problem but clearly there is not.  

    Thanks guys :-)


    Thursday, October 27, 2016 7:48 AM
  • What about creating a dedicated hotspot for mobile devices and preventing internal dns access.
    Thursday, October 27, 2016 8:11 AM
  • Hello, 

    Currently where does the meet.domain.com internal url pointing to , If they are also pointed to the rP then we can go ahead with a third party certificate so that it can  pass the authentication


    Linus || Please mark posts as answers/helpful if it answers your question.

    Thursday, October 27, 2016 8:59 AM
  • Yep totally understand the issue here and the smartphone app works fine as it should on internal wireless via the rev proxy.  all good.

    But for the web app on the smartphone option, yes we have considered using a public CA for the FE servers but in reality I think it will be easier to install the internal cert chain onto the smartphones.

    TBH I dont see this as a massive issue for smartphones on internal wireless as if presented with the choice of S4B mobile app or web app then im sure most users will click the S4B mobile app for full functionality.

    Cheers I just wondered if there was a more up to date work around of this problem but clearly there is not.  

    Thanks guys :-)


    Hi Dazzler,

    For mobile client, it must use public CA, because it will join meeting from external.

    If there are any questions or issues, please be free to let me know.



    Best Regard,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Marked as answer by jim-xu Monday, November 7, 2016 1:55 AM
    Tuesday, November 1, 2016 6:42 AM