Skype For Business Problem Verifying Certificate

by



Asssuming you have a Certificate Authority in your domain, go that machine and create a root certificate (if you have not created one before). Install that certificate in the machine (which is not in AD) in the trusted root folder. Now try logging into the Communicator. Microsoft releases May 7, 2019, update for Skype for Business 2015 (Lync 2013) (KB4464547) Microsoft releases May 7, 2019, update for Skype for Business 2016 (KB4464532) Microsoft releases April 2, 2019, update for Skype for Business 2015 (Lync 2013) (KB4462207) Microsoft releases April 2, 2019, update for Skype for Business 2016 (KB4462234).

-->

Symptoms

This article describes two scenarios that occur when the Microsoft Lync client can't establish a trust relationship with resources that require a secure TLS connection.

Scenario 1

When a user tries to sign in to Microsoft Lync in a Lync Server 2013 environment for the first time, she receives the following message in a dialog box:

For example, the following trust model dialog box is displayed:

Scenario 2

The Lync – Sign In dialog box that's shown in the screen shot in Scenario 1 displays the fully qualified domain name (FQDN) of the organization's Exchange Client Access server (CAS) interface. This interface is used by the Lync client to access user mailbox information through Exchange Web Services (EWS). This behavior occurs if the Lync user's SIP URI contains a domain suffix that does not match the domain suffix of the Exchange CAS interface. If the user chooses not to trust the connection to the Exchange CAS interface, the Lync client will not have access to the Exchange mailbox services that are provisioned by EWS.

Verifying

To verify this behavior, follow these steps:

  1. Make sure that the Lync client is signed in to on the Windows client's desktop.
  2. Hold down the CTRL key and right-click the Lync icon in the Windows client's notification area.
  3. In the shortcut menu, click Configuration Information.
  4. Locate the 'EWS Information' line.
  5. If this line contains 'EWS not fully initialized,' you are experiencing the Scenario 2 behavior.

Cause

This issue occurs because the SIP domain name of the user does not match the domain names in the following properties in the certificate of Lync Web Services and Exchange Web Services:

Problem
  • Subject Name
  • Common Name

Resolution

To prevent display of the Trust Model dialog box, use the Trusted Domain List (TrustModelData) Group Policy. After you set this policy, Lync will exclusively trust the domains that are specified in the policy. Supported values:

  • Not Configured (Default)/Disabled

    Through this setting, the following domains are trusted by default:

    • lync.com
    • outlook.com
    • lync.glbdns.microsoft.com
    • microsoftonline.com

  • Enabled

    This setting specifies the list of domains to be trusted—for example: contoso.com, contoso.co.in.

For more information about the Lync 2013 Trusted Domain List (TrustModelData) Group Policy setting, see Configuring client bootstrapping policies.

For more information about the Lync 2013.admx (ADMX) and .adml (ADML) Administrative Templates, see Office 2013 Administrative Template files (ADMX/ADML) and Office Customization tool.

More Information

Scenario 1

The Lync 2013 desktop client uses the new automatic discovery mechanism to locate the internal or external Lync Web Service, depending on the network location of the user.

The following process occurs when the Lync 2013 desktop client tries to locate the Lync Web Service:

  1. The Lync 2013 desktop client sends a pair of HTTP and HTTPS requests to locate the Lync Autodiscover Service. The HTTP and HTTPS requests consist of a default set of internal or external host name values and the SIP domain name of the user.

    For example, the Lync 2013 desktop client sends the following requests:

    http://LyncdiscoverInternal.contoso.com and https://LyncdiscoverInternal.contoso.com

    Note

    'LyncdiscoverInternal.contoso.com' is resolved to the FQDN or IP address of the Internal Lync Web Service.

    http://Lyncdiscover.contoso.com and https://Lyncdiscover.contoso.com

    Note

    'Lyncdiscover.contoso.com' is resolved to the FQDN or IP address of the external interface of the Reverse Proxy.

  2. The Lync 2013 desktop client receives a response that contains the secure internal and external URLs of the Autodiscover Service from Web Services.

  3. The Lync 2013 desktop client tries to contact the Autodiscover Service by using an HTTPS connection. If the SIP domain name of the user does not match the domain name in the Subject Name or Common Name property on the certificate that is assigned to Lync Web Service, the Trust Model dialog box is displayed.

Skype For Business Problem Verifying CertificateSkype

Scenario 2

The Lync client makes https requests to the Exchange CAS interface as part of its post-sign-in process. These requests include access to the Exchange Autodiscover service through URLs that include the FQDN of the Exchange CAS interface. For example:

  • https://<smtpdomain>/autodiscover/autodiscover.xml
  • https://autodiscover.<smtpdomain>/autodiscover/autodiscover.xml

If the FQDN of the SMTP domain does not match the FQDN of the SIP domain that the Lync client is signed in to, the Scenario 2 issue occurs.

Still need help? Go to Microsoft Community.

Changing an expired SSL certificate is easy in Exchange 2016 using the EMC. A simple click or two, and boom… new certificate!

Unless you have integrated Skype for Business IM into your OWA.

Symptoms
1st Symptom: User Complaints
2nd Symptom: Your exchange logs the following event:

The certificate specified by the InstantMessagingCertificateThumbprint parameter of the Outlook Web App virtual directory wasn’t found in the local certificate store.
Certificate thumbprint:

Yup.. you have a couple of more steps to complete.

STEP#1: Get the new thumbprint

  1. Launch Exchange Management Shell as an Administrator
  2. Execute
    Get-ExchangeCertificate
  3. Copy the Thumbprint of the certificate that has registered the “W” service
    NOTE: That same certificate may have registered other services like the certificate example below, which has registered IPUWSC services.

STEP#2: Update the OWA virtual directory with the new thumbprint

  1. Launch Exchange Management Shell as an
    Administrator
  2. Execute
    get-owavirtualdirectory | Set-OwaVirtualDirectory -InstantMessagingCertificateThumbprint [THE NEW THUMBPRINT]

STEP#3: Update the OWA configuration file

  1. Open the OWA configuration file located at
    C:Program FilesMicrosoftExchange ServerV15ClientAccessOWAweb.config
  2. Search the configuration file for “IMCertificateThumbprint”
    Important: If the key does not exist in the web.config, proceed to STEP#3A below
  3. Change the key thumbprint to the new thumbprint value
    <add key=”IMCertificateThumbprint” value=”[THE NEW THUMBPRINT” />
  4. Restart IIS and test IM in OWA
  5. Your Done! Stop here!

STEP#3A: Update Setting Overrides

  1. Launch Exchange Management Shell as an Administrator
  2. Execute
    Get-SettingOverride
  1. You should get an output like the following
    Closely note the following values
    – Id {In the example above, the value is OWA-SKYPE-INTEGRATION
    – Parameters, specifically the IMServerName value {In the example above, the value is SRVSKYPE15FE.corp.armgasys.com
  2. Execute
    Set-SettingOverride -Identity [ID NAME] -Parameters @(“IMServerName=[SERVER NAME]”,”IMCertificateThumbprint=[THE NEW THUMBPRINT]”)
  3. Make sure everything is refreshed by executing the following command
    Get-ExchangeDiagnosticInfo -Server $ENV:COMPUTERNAME -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
  4. Restart IIS and test IM in OWA
Certificates

Skype For Business Online There Was A Problem Verifying The Certificate From The Server

Good Luck!